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ABSTRACT 


Complex defense acquisition programs, such as the Global Positioning 
System program, have many requirements engineering challenges to overcome 
in order to deliver capabilities to customers and satisfy other stakeholders. To 
meet these challenges and stay within cost and schedule constraints, engineers 
and managers need system requirements information organized in a clear, 
complete, and efficient manner to support decision making. An effective 
methodology tailored to the needs of the program decision makers will ensure 
that important information is correct, organized, and readily accessible. The GPS 
program is implementing a methodology that includes standardized processes 
across its segments. However, the GPS program refrained from implementing a 
better requirements engineering approach and using its current requirements 
engineering tool to take advantage of this approach. 
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I. INTRODUCTION 


A. BACKGROUND 

With the Global Positioning System (GPS) program as an example, this 
research pursued the discovery of efficient and thorough methods for integrating 
system requirements across generations of system deliverables that incorporate 
new technologies and capabilities. Known as the Navstar GPS Joint Program 
Office until it was renamed in August 2006, the GPS Wing is the United States 
Air Force (USAF) system program office responsible for planning and acquiring 
deliverables that provide new GPS-based capabilities. Current practices expose 
the GPS program to the risk that technical incompatibilities will result across 
different blocks or generations of subsystems and their hardware and software 
interfaces. The reason for this is that not all relevant information is recognized 
and controlled by a central authority through a single, formal methodology. This 
research identified a more effective methodology for tracking the impact of every 
change or proposed change made to the GPS technical baseline. The GPS 
Wing could implement this approach with its existing requirements engineering 
tool, Telelogic AB’s DOORS 7.1 database, and provide better decision-making 
support to GPS Wing leaders as a result. 

The pursuit and recognition of valuable and timely information is a quest 
that persists for decision makers. Having ready access to knowledge of decision 
impacts across system segments and their successive deliverables would allow 
program decision makers to balance various and often competing system 
program objectives confidently. The outcome of this research recommends and 
demonstrates a requirements engineering methodology that helps systems 
engineers to answer the research questions posed below. When implemented 
fully, the GPS program’s systems engineers should be able to take advantage of 
this methodology to perform quick and comprehensive technical analyses that 
support recommendations to the GPS Wing Commander. The GPS Wing 
Commander serves as the GPS System Program Director (SPD). 
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B. PURPOSE 

The greater purpose of this research effort was to offer requirements 
engineering improvements within the GPS program that systems engineers 
outside of the GPS Wing could apply for the benefit of their own acquisition 
programs. Programs that could benefit include other space programs that are 
held in the Space and Missile Systems Center (SMC) portfolio of acquisition 
programs at Los Angeles Air Force Base. (SMC funded the author’s participation 
in the degree program for which this thesis satisfies a graduation requirement.) 
Ultimately, this research effort establishes an appropriate requirements 
engineering methodology for the GPS program and contributes to the set of best 
practices that help systems engineers and program managers for any complex 
system improve the level of cost, schedule, and technical success of their 
respective programs. 

C. RESEARCH QUESTIONS 

The following research questions describe the extent of discussions that 
involved this author and other members of the GPS Wing at the onset of this 
research effort. This paper addresses all of these questions. 

1. If the GPS program makes a decision to change a number in one 
place in the requirements or specifications, how does the program track 
and assess the impacts or ripples across system segments and 
capabilities? This question includes the following facets: 

a. Requirements traceability 

b. Requirements effectivities 

c. Offline tools 

d. Varying classification levels 

e. Contracts 
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2. What does the current requirements engineering technology, 
DOORS, do well for the GPS program and what does it fail to do well or at 
all for the program? 

3. In what ways are requirements documented? 

4. What should the GPS program do about requirements that it 
anticipates and will affect other subsystem or segment deliverables, but do 
not exist yet? 

For example, there will be a requirement to monitor the newest GPS 
signals. One satellite that can broadcast the M-Code signal is in orbit 
already, but it will be years before the GPS has a monitoring capability 
to support future GPS users of this type of signal. 

5. What are the appropriate roles and relationships of the Capabilities 
Development Document (ODD), specifications, and Interface Control 
Documents (ICDs)? 

a. For example, is the word shall in ICDs appropriate or, rather 
than provide direction, should ICDs simply describe interfaces? 

b. How are ICDs handled in contracts when compared to other 
documents? 

6. How should the program state requirements when perspectives 
differ across subsystems and segments? 

7. What are the characteristics of a “good” requirement? 

8. How can the program capture the rationale behind a requirement? 
It can be important to know whether a requirement exists because it is 
achievable or because of analysis. 

9. How do a vendor and client verify that a particular requirement has 
been satisfied? 

10. Who are the GPS program’s customers and other stakeholders? 
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Figure 1 below shows one way to organize these questions to see how 
they relate to each other in the context of system requirements engineering. 
There are four categories into which these research questions fit, and these are 
summarized as the following general questions: 

• Where do requirements come from? 

• How do we state requirements effectively? 

• How should we document requirements? 

• How should a program handle requirements changes? 


Where do reqts come from? 


Who are the GPS 
program’s customers and 
other stakeholders? 


What processes' 
between sources 

define interaction 
& documentation? 


What are the appropriate 
roles & relationships 
among the CDD, system 
specs, ICDs, & ISs? 





How should the program state 
re qts effectively? _ 


What are the 
characteristics of a 
good requirement? 


How should one state 
reqts to accommodate 
perspectives across 
subsystems & segments? 


How can the program 
capture the rationale 
behind a requirement? 


How do a vendor and 
client verify that a 
requirement has been 
satisfied? 


How should a program document 
requirements? 


How does the GPS 
program document 
requirements? 


What does DOORS do 
well for the GPS program 
and where is there room 
for improvement? 


How should a program handle 
reqts changes? 

What is the best way to 
handle anticipated reqts 
that will affect other 
subsystems & segments? 


How does program track 
& assess impacts of 
reqts changes across 
segments & capabilities? 


Figure 1. Relationship of Research Questions to Requirements Issues 
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D. BENEFITS OF STUDY 

1. Disciplined and Comprehensive Requirements Engineering 
Methodology 

A methodology can assist with analyzing the impacts of the factors and 
influences that contribute to the requirements engineering challenge. A 
methodology consists of three main components: techniques, models, and tools. 
Satzinger, Jackson, and Burd help to define this whole and its components, 
which are paraphrased as follows: 

a. Methodology = guidelines for completing activities in a 
system development life cycle that include models, tools, 
and techniques 

b. Model = a representation or abstraction of something real 

c. Tool = something that helps with the creation of models or 
some other means to support a project 

d. Technique = guidelines such as step-by-step instructions or 
general advice for completing an activity/task 

(After Satzinger, Jackson, & Burd, 2004) 


2. Improved Decision Support Resources for Program Managers 
and Systems Engineers 

The GPS program faces many complex programmatic, technical, and 
political challenges. Effective documentation, analysis, management, and 
reporting tools for system requirements help program managers and systems 
engineers understand the impacts of decision alternatives and ensure that they 
make informed decisions. As this research revealed, the GPS Wing uses the 
DOORS tool without taking advantage of its most powerful features. Used with a 
more effective requirements-centric model, the DOORS tool can help decision 
makers improve the speed and quality of these decisions that affect the evolution 
of the GPS. 
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E. SCOPE AND METHODOLOGY 

1. Thesis Scope 

The thesis focuses on improving the models, tools, and techniques that 
support GPS requirements engineering from the elicitation of well-defined 
requirements from customers through the integration and test of deliverables. 
The requirements engineering recommended improvements can ensure that 
deliverables as designed and produced will satisfy well-defined requirements. 
This thesis addresses current shortfalls and concerns identified above in the 
research questions. In particular, the research findings include a better method 
for ensuring that potential impacts of new or modified requirements are easy to 
trace quickly. These improvements would benefit affected stakeholders who 
could then analyze the impacts and help program leaders make balanced 
decisions. 

2. Approach/Methodology 

This section summarizes the activities that contributed to the research 
results and conclusions for this paper: 

a. A literature review of requirements engineering best 

practices and GPS requirements 

b. Interviews of GPS program key personnel to uncover 

shortcomings in integrating requirements effectively 

c. Identification of current GPS requirements engineering 
issues 

d. Establishment of a DOORS account and receiving DOORS 
training 

e. A review of how requirements from various relevant 

documents are currently handled in DOORS or by other means 

• system specifications and derived documents 
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• Interface Control Documents (ICDs) and Interface Specifications 
(ISs) 

• the Capabilities Development Document (CDD) and its predecessor 
documents, 

• requirements documents classified at various levels 

f. Identification of examples of how processes and resources 
could be used to track requirements more effectively in order to facilitate 
better and faster requirements engineering decisions 


F. ORGANIZATION OF THESIS 

Chapter I provides an introduction to the GPS Wing’s requirements 
engineering challenges. In Chapter II, this paper introduces the GPS acquisition 
program and its stakeholders. Chapter II addresses the research question 
regarding where requirements come from and also describes the requirements 
management process. After explaining how the GPS Wing currently documents 
requirements, Chapters III and IV discuss the remaining three categories of 
research questions from Figure 1 above. While Chapter III focuses on an 
explanation of the contents within the literature reviewed, Chapter IV focuses on 
the application of the knowledge gained from both the literature reviewed and 
interviews granted by GPS Wing personnel. Chapter V provides a summary of 
recommendations and proposes areas for conducting additional research. 
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II. THE GLOBAL POSITIONING SYSTEM (GPS) ACQUISITION 
PROGRAM AND STAKEHOLDERS 


A. THE GLOBAL POSITIONING SYSTEM (GPS) 

The GPS is a space-based precision position, velocity, and timing (PVT) 
system conceived as a U.S. joint civil-military system led and staffed by the 
United States Air Force with participation by a variety of other U.S. government 
agencies and foreign military representatives. Other terms that describe GPS 
appropriately are Global Navigation Satellite System (GNSS) and Radio 
Navigation Satellite Service (RNSS), because the coverage provided by the GPS 
is global and it transmits radio frequency signals on L-band carrier frequencies 
(from 1 GHz to 2 GHz according to IEEE standards) to the GPS users. GPS’s LI 
and L2 center frequencies are 1.57542 GHz and 1.22760 GHz, respectively. 
Figure 2 below depicts the segment components of the GPS and may serve as a 
helpful visual reference for the more detailed explanation that follows. 
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Master Control 
Station (MCS) 



Monitoring 

Stations 


Figure 2. General depiction of the Global Positioning System segments (After 

Kaplan, 2006) 

The space, ground (or control), and user segments represent the critical 

components of the GPS architecture. From the master control station (MCS) or 

its alternate facility, satellite operator personnel command and control the 

constellation of satellites that broadcast signals to monitoring stations (to create a 

feedback loop) and to GPS users. Users fall into two general categories: civil or 

military. Civil users benefit from the Standard Positioning Service (SPS) enabled 

by the coarse/acquisition (C/A) code signals broadcast by GPS satellites at the 

LI frequency. Military users also have access to the encrypted Precise 

Positioning Service (PPS) that is based on the encrypted signal known as P(Y) 
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code, and this signal is broadcast at the LI and L2 frequencies. If the SPS is not 
augmented by a regional ground-based or space-based differential GPS system, 
the PPS will provide more accurate results than the SPS. The National Security 
Agency (NSA) supports the cryptography needs of the GPS program. 

GPS receivers on or above the surfaces of the earth receive signals that 
are broadcast from multiple GPS satellites to derive accurate ranging information 
with respect to each satellite and calculate unique PVT information for each user 
in real time. These signals are a combination of carrier frequency at which the 
GPS receivers receive the signals, a navigation message, and a ranging code. A 
GPS satellite’s unique ranging code enables receivers—with their satellite 
constellation almanacs—to distinguish among the satellites in order to determine 
which satellites are “in view.” The use of these unique codes is necessary, 
because unlike radio stations that each use different frequencies to broadcast 
their content, the GPS signals from each satellite use the same carrier 
frequencies for the same purposes. The information regarding ranges to 
particular in-view satellites allows receivers to calculate their PVT information. 
More satellite signals available to a receiver typically result in better calculated 
solutions, but the relative positions of the satellites (the geometry) influence the 
accuracy of the calculations also. A minimum of four uncorrupted or “healthy” 
satellite signals are necessary for accurate position information. The reason that 
four satellites are needed instead of only three is that the ranging equations that 
describe the distance each signal travels from each satellite to a receiver include 
the 3-dimensional coordinates for the in-view satellites, the coordinates for the 
receiver, and the receiver’s clock bias with respect to the satellites clocks. In 
general algebraic terms, the receiver would need four equations (one for each of 
four ranging signals) in order to solve for the four unknowns: the user’s x, y, and 
z coordinates and receiver clock bias. Not taking into account the clock bias in a 
receiver can result in position errors of several hundred meters even with the 
most advantageous relative positions of only three satellites to each other and 
the user. Knowing deviations from expected satellite ephemerides also improves 
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the accuracy of receiver-calculated positions. Ample technical sources provide 
more detail about general GPS receiver technology. As of 2006 and in 
unobstructed settings, receivers can typically track eight or more GPS satellites 
than are needed to provide accurate results to users (Kaplan & Hegarty, 2006). 

Satellite operators who work at the Master Control Station command and 
control the satellites of the GPS constellation. The operators ensure that the 
control segment performs the following functions defined by Misra and Enge: 

• to monitor satellite orbits 

• to monitor and maintain satellite health 

• to maintain GPS Time 

• to predict satellite ephemerides and clock parameters 

• to update satellite navigation messages 

• to command small maneuvers of satellites to maintain orbit, and 

relocations to compensate for failures, as needed 

(Misra & Enge, 2001) 

Some of the functions above relate to the new navigation messages the 
operators create and transmit to satellites in order maintain the GPS 
performance. Operators predict ephemerides and clock parameters using data 
obtained from the monitoring stations dispersed around the globe, and provide 
these predictions in the navigation message that is uploaded at least one each 
day to each satellite via ground antennas. Deviations from expected satellite 
orbits (or ephemerides) occur as a result of astronautical phenomena such as 
solar pressure and because the operators’ gravity model is not perfect. The 
result of clock predictions is a definition of GPS Time and an effective 
synchronization of GPS satellite atomic clocks. These clocks are subject to very 
small errors that are still large enough to cause significant errors (several 
hundreds of meters in position) in receiver position calculations. GPS clocks use 

either cesium or rubidium frequency standards that are among the most stable 
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and precise clocks in existence. With the clock and ephemerides error 
information broadcast via the navigation message to and then from satellites, 
users’ receivers can reduce the amount of error in their calculated PVT solutions. 
As the amount of time increases from the last update to the navigation message, 
the magnitude of PVT errors increases with the increasingly older satellite clock 
and ephemerides parameters. 

The orbits for the GPS constellation include 24 primary orbital slots—one 
for each satellite and four in each of six orbital planes to provide nearly even 
coverage around the globe. For several years, there have been surplus satellites 
distributed (not necessarily evenly) across the planes of the constellation and 
contributing to the quality of the PVT information provided to users. Older 
satellites that are closer to failure tend to be placed near other such satellites 
either in the same plane or in adjacent planes to ensure robust coverage around 
the globe. Constellation management decisions like these involve analysis of the 
most likely failure scenarios and their impacts. An AFSPC-wide community 
meets quarterly to make decisions that sustain the GPS constellation and 
minimize the service degradation in terms of duration and geographic footprint on 
any given day. This body takes into account the health risks forecasted for each 
satellite and each plane of satellites. Because each operational satellite makes 
an impact on system performance, decisions that contribute to this robustness 
often involve combining decisions to choose orbital destinations for new satellites 
and to reposition satellites currently in the constellation. Ultimately, this body 
shares the GPS stakeholders’ number one priority to sustain the GPS service at 
a high level of quality. 

B. THE GLOBAL POSITIONING SYSTEM (GPS) WING 

1. Organization 

The GPS Wing is a program office responsible for the acquisition and 
evolution of the GPS. Several program office Divisions, Groups, and support 
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contractors support the Wing Commander in his role as System Program Director 
(SPD). These organizations fall into five general categories shown in Figure 3: 


PRODUCT DEVELOPMENT 

GROUPS & PRODUCT 

SUPPORT DIVISIONS 

-Space Segment Group 
-Control Segment (CS) Group 
-CS Support Division 
-User Segment Group 
•User Equip. Support Division 


CORPORATE SUPPORT 

-Aerospace Corporation 
-MITRE Corporation 
-System Engineering & 
Technical Assistance 
(SETA) support contractors 
-Admin & computer tech 
support contracts 


FUNCTIONAL SUPPORT 

DIVISIONS 

-Systems Engineering 

-Contracting 

-Logistics 

-Management Operations 
-Program Control 


OTHER PAYLOAD DIVISION 

-Nuclear Detonation 
(NUDET) Detection 

System (NDS) 


STAKEHOLDER DIVISIONS 

-Army 
-Civil Users 
-National Geospatial 
Intelligence Agency (NGA) 
-Navy 


Figure 3. GPS Wing’s Division, Group, and Corporate support for the SPD 

2. Roles and Responsibilities 

a. Product Development and Product Support 

The GPS Wing has a product development Group for each of the 
three GPS segments: ground (or control), space, and user. They each manage 
their own development contracts, and work with the System Engineering and 
Logistics Divisions to ensure compatibility of requirements, effective integration, 
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test, delivery, and user acceptance of new system components. The Contracting 
and Program Control Divisions also support the changing needs of these 
acquisition efforts. 

The Space Segment Group is responsible for the acquisition of the 
space vehicles. Current acquisition efforts include the Block IIR-M satellites, 
some of which remain to be launched, the Block 11F satellites being 
manufactured, and the Block III variants for which the GPS Wing has not chosen 
a vendor. 

The Control Segment Group is responsible for the upgrade of the 
current and acquisition of the new ground infrastructure necessary to command 
and control the space vehicles. This infrastructure includes master control 
stations (primary and backup), ground antennas, monitoring stations, other 
communications equipment (switches, routers, and transmission lines) to connect 
these modules, and the software necessary to integrate and operate this 
equipment. Software acquisition is a challenging part of the Control Segment 
modernization that has resulted in cost and schedule overruns. The Control 
Segment also uses the Air Force Satellite Control Network (AFSCN) Remote 
Tracking Stations (ARTS) to support testing and satellite orbital movement 
operations, and National Geospatial Intelligence Agency (NGA) monitoring 
stations to augment the GPS monitoring stations around the world. 

The Control Segment Product Support organization in Colorado 
Springs, CO provides product maintenance and upgrade services requested by 
the operators. Upgrades can include changes to the user interface or additional 
functions. 

The User Segment is responsible for the acquisition of GPS PPS 
receivers used by U.S. and allied foreign military services. Products acquired by 
this segment include the Precision Lightweight GPS Receiver (PLGR) handset 
and the Combat Survivor Evader Locator (CSEL) system. Current acquisition 
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programs include more advanced hand-held and platform-mountable receivers 
for navigation and precision targeting. 

The User Equipment Support Division at Robbins Air Force Base, 
GA provides support for the GPS military receiver users. This support includes 
user training as well as equipment maintenance, troubleshooting, and upgrades. 

b. Corporate Support 

Like the other program offices at the SMC, the GPS Wing relies on 
the invaluable technical support provided by corporate partners. These include 
the The Aerospace Corporation, The MITRE Corporation, and System 
Engineering and Technical Assistance (SETA) contractors. 

The Aerospace Corporation and The MITRE Corporation are both 
Federally-Funded Research and Development Corporations (FFRDCs) that 
receive funding from Congress and operate as non-profit corporations. This 
allows employees of both corporations to have the privilege of access to vendors’ 
proprietary information when such access is necessary to support official 
government business. This information is usually technical in nature since most 
employees of these FFRDCs are engineers or their managers. This special 
status precludes these FFRDCs from competing against vendors who do operate 
for profit. Aerospace has its headquarters adjacent to Los Angeles Air Force 
Base in El Segundo, CA and has the larger presence of the two firms. MITRE 
has its headquarters in Bedford, MA and an office in El Segundo, CA. 

Apart from the FFRDCs, for-profit contractors compete for SETA 
contracts to support the GPS Wing’s technical needs. Employees of these firms 
support the GPS Wing in a manner similar to that of the FFRDCs. At the time of 
this research effort, these firms included ARINC Engineering Services, LLC of El 
Segundo as prime contractor; Science Applications International Corporation 
(SAIC); Tecolote Research, Inc.; Overlook Systems Technologies, Inc.; and 
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Teledyne Brown Engineering, Inc. Different firms support administrative and 
information technology needs through other contracts. 

c. Functional Support Divisions 

The functional support divisions along with their assigned corporate 
supporter team members serve to accommodate and balance the needs of the 
product development groups and product support organizations, represented 
stakeholders, and the NDS program. 

The GPS Wing’s Systems Engineering Division guides the analysis 
and design of the GPS system architecture and capabilities. This work includes 
defining and coordinating requirements documents that include the Capability 
Development Documents (CDDs), system and segment specifications, interface 
control documents (ICDs), Interface Specifications (ISs), and other technical 
guidance necessary to meet operator and user needs. Vendors use this 
guidance to design their subsystems and validate the performance of these 
designs. All stakeholders voice their input to ensure that program decisions 
accommodate their needs. The Chief Engineer and ultimately the Wing 
Commander balance these needs based on the guidance and direction from the 
DoD, regulatory bodies, and the needs of the GPS stakeholders. Section D1 
explains the division of responsibilities within the Systems Engineering Division. 

The Chief Engineer, Group Commanders and Wing Commander 
cannot make informed decisions without consulting with the GPS Wing’s 
Program Control Division. This division has financial and cost analyses branches 
to help ensure that the program only takes actions that the Wing’s budget will 
allow. While the Systems Engineering Division focuses on technical baselines 
and the Program Control Division focuses more on cost and schedule baselines, 
both divisions must work together with the product development groups to 
balance cost, schedule, and technical needs of the GPS Wing’s acquisition 
programs. The Program Control Division also serves as the focal point for 
external (DoD) requests for analysis. 
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By negotiating contracts with vendors, the GPS Wing’s Contracts 
Division works with the product development groups to ensure that these firms 
will design and build GPS subsystems in accordance with the compliance 
documentation included on the respective contracts. The Contracts Division 
manages several development contracts and oversees the bidding for others like 
the separate Space and Control Segments’ Block III contracts. Control over 
these contracts is important for ensuring that the multiple prime contractors 
deliver GPS subsystems that will work properly with the other vendors’ 
deliverables. 

The GPS Wing’s Logistics Division works with AFSPC to meet the 
integrated logistics support (ILS) needs of the GPS program. Capt M. Ewer of 
the Logistics Division (personal communication, July 10, 2006) describes the 
division of responsibilities as they are summarized in Table 1 below: 


GPS Wing-Level Lead 

AFSPC-Level Lead 

• Maintenance planning 

• Support and Test Equipment/ 

• Supply support 

Equipment support 

• Training & training support 

• Manpower and personnel 

• Technical data 

• Computer Resources support 

• Packaging, Handling, Storage, 

• Facilities 

and Transportation (PHS&T) 


• Design interface 



Table 1. ILS elements allocated among GPS Wing and AFSPC levels. 


The GPS Wing’s Management Operations Division provides office 
support functions to meet the personnel and office needs for all GPS Wing 
employees. 
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d. Other Payloads 

The non-PVT payload that the GPS program supports is the 
Nuclear Detonation (NUDET) Detection System, or NDS. The DoD decided to 
add this payload to the GPS space vehicles in order to leverage the continuous 
global coverage that the GPS provides. 

e. Stakeholders 

As stakeholders in the evolution of the GPS, other government 
agencies have GPS Wing division-level offices to represent them within the GPS 
program. These entities include the other US military services, the National 
Geospatial Intelligence Agency, and civil users. 

The Army’s and Navy’s concerns relate directly to the quality of 
PVT services provided to their respective members through their diverse GPS 
receiver equipment sets. There are many adaptations of GPS receivers to the 
needs and platforms of various military systems. 

Known previously as the National Imagery and Mapping Agency 
(NIMA), the National Geospatial Intelligence Agency (NGA) provides the 
information necessary to relate GPS coordinates to the geographic features of 
the world. Modeling the geographic features of the earth is part of a discipline 
known as geodesy. 

The civil users collectively include more people than military users, 
and the number of civil applications continues to expand. While these users 
include emergency responders, surveyors, members of the agriculture industry, 
athletes, and many others, the civil agency most interested in the evolution of the 
GPS is the United States Department of Transportation (DoT). Within the DoT, 
the Federal Aviation Administration (FAA) has a strong interest in understanding 
and influencing policy and technical decisions for the GPS in order to support the 
needs of civil aviation navigation and the Wide-Area Augmentation System 
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(WAAS). This system would include geosynchronous satellites to work with the 
GPS to improve GPS accuracy and availability to satisfy civil aviation navigation 
and safety requirements. 

The satellite launch community participates in constellation 
management decisions because the GPS program must coordinate the timing of 
its launch plans with the launch pad schedule controlled by the launch 
community. Launches are planned several years in advance, and are subject to 
changes based on DoD and national needs. 

3. GPS Program Requirements Challenges 

With the diverse sources of change to the system that include the 
functional support divisions, product development groups and product support 
organizations, and other stakeholders, there exists the risk that requirements 
generated or requirements changes made for one part of the program will have 
unintended consequences that are difficult to trace or accommodate. The 
Systems Engineering Division has the Herculean task of managing the 
complexity of the GPS program, and the tools used and frequent turnover 
common in military organizations are among the sources of confusion and risk for 
which a stricter approach to requirements engineering could help ensure more 
effective integration of the system’s components across system segments. 
Every requirements integration/engineering activity should strengthen the 
program’s ability to fulfill its mission and obligation to its stakeholders. These 
engineering impacts will not occur without contractual, cost, and/or schedule 
implications. 

The GPS program faces engineering challenges, different rates of 
modernization progress across the three segments, and a tremendous amount of 
interest and use beyond the Department of Defense. With respect to the latest 
signals and associated services, Control Segment modernization lags behind 
Space Segment modernization, and both lag User Segment modernization. For 

several years, users have had GPS receivers that are capable of operating within 
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the improved GPS security architecture that the Control Segment will not be able 
to implement for at least two more years. While it is necessary to have satellites 
in orbit that can support the newest planned capabilities before they are 
implemented by the Control Segment, the Control Segment lags far enough in 
development that it cannot support requirements engineering work needed for 
the Space Segment to continue its own software development efforts. Also, 
influences outside of the Department of Defense further complicate plans to 
modernize GPS. These constraints include domestic and international laws and 
regulations, other U.S. government agencies’ and commercial interests, and 
international agreements. Program managers and systems engineers must be 
aware of these constraints as they contend with the realities of the acquisition 
program baseline. 

C. THE GPS ACQUISITION PROGRAM BASELINE (APB) 

1. Overall 

The APB describes the delivery of GPS upgrades and capabilities: 
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Concept l l Production (S) APB Milestone /\ Milestone Objective r 

Objective _ 

Development ^^Bl Platforms / Fielding (Mar 05) L 


Ti Phase 1 - Initial Test 

^ Phase 2 -Enhanced T&M 


Phase 3 - Initial PVT (IOC) 

Phase 4 - Full PVT (FOC) 


Figure 4. April 05 GPS Enterprise Schedule (D’Alessandro & Turner, 2006) 

Figure 4 summarizes the timing of GPS modernization activities. The top 
portion of the figure lists the new capabilities that the GPS will provide over time, 
while the bottom three sections devote themselves to summarizing the 
modernization of the three GPS segments. It is through the modernization of 
these segments that the new features will become available to GPS users. 
Acronyms in Figure 4 are defined as follows: 

• Phase 2 - Enhanced Timing and (Navigation) Messaging (T&M) refers to 
an improvement in both of these named capabilities 
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• Initial Operational Test and Evaluation (IOT&E) is a phase of 
system testing in an operational environment 

• The Preliminary Design Review (PDR) is the forum for the 
appropriate program manager to determine whether or not “test and 
analytical evidence... prove that all performance numbers are achievable 
and no significant performance risk remains, and [whether or not] the end 
product will satisfy the customer” (Forsberg, Mooz, & Cotterman, 2000). 

• The Critical Design Review (CDR) is the forum for the appropriate 
program manager to determine whether or not “tests and 
demonstrations... prove that building and coding to the proposed 
documentation is achievable with acceptable risk and, [whether or not] the 
end product will satisfy the customer” (Forsberg, Mooz, & Cotterman, 
2000 ). 

• Telemetry, Tracking, and Control (TT&C) is the name for the 
information provided by a communications bus. 

o Telemetry is any information transmitted from a remote 
location. 

o Tracking relates to information used to determine changes in 
satellite position. 

o The system operators control the satellites with messages 
provided via the TT&C communications bus. 


2. New Capabilities 

New capabilities will include incremental security architecture 
advancements known as (Block I IF) SAASM and Block III Mil Protect. Newly- 
designed signals will also be broadcast at frequencies and power levels that 
conform to U.S. and international regulatory filings. Before any new capability 
becomes available, each segment modernization effort must achieve its own 
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milestones in order to support delivery of the capability. The difficulties in 
achieving these milestones are revealed below in the respective segment 
sections. 

The second-generation security architecture and third-generation 
cryptography are known collectively as SAASM. This acronym is misleading 
because if represents more than the Selective Availability Anti-Spoof Modules in 
GPS receivers that have been available to the P(Y) code-based Precise 
Positioning Service (PPS) users for years. When supported by the Block 11F 
control segment, the capabilities linked to SAASM will improve cryptographic key 
distribution to PPS receivers (used mostly by military users) and reduce their 
susceptibility to spoofed GPS signals that can lead to significant PVT errors. 

Block III advancements are expected to include another civil signal, 
controlled signal power generation, and another security architecture 
improvement. The Block III security architecture that will replace SAASM is 
known as Military Protect and will work with the M-Code-based PPS. The term 
M-Code is the accepted shorthand for the new Military Code ranging signal. 
Flex-power will be a capability to increase the GPS signal power to support 
military needs in chosen parts of the world. L1C will be new civil signal 
broadcast by the GPS Block III satellites. 

L2C, L5, and L1C are the L-band civil signals listed in the order they will 
reach Initial Operating Capability (IOC) and Full Operating Capability (FOC). 
These signals are shown in the GPS Capabilities section of the GPS Enterprise 
Schedule in Figure 4. FOC for a type of signal requires 18 healthy satellites to 
broadcast it. Note that only users who have receivers capable of processing 
these new signals will benefit from the capabilities offered. The M-Code signal 
and Flex-Power feature will achieve IOC at the same time as the L2C signal. 
The reason for the expected simultaneous realization of these signals and 
capabilities is that these all depend on Block IIR-M satellites and the satellite 
variants that will follow. Refer to Figure 4 to see this type of connection between 

the GPS segment deliverables and capabilities. 
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3. Space Segment 

The remaining Block II generation of satellites that will provide new signals 
includes the Lockheed Martin Block IIR-M and the Boeing Block I IF satellites. 
The IIR-M vehicles can broadcast the L2C Civil Signal and the M-Code military 
signal. The Block 11F satellite will also broadcast the L5 civil signal, which is of 
particular interest to the DoT and FAA for civil aviation use. 

The GPS Wing has not chosen the vendor that will design and build the 
Block III generation of satellites, but these satellites will add the L1C civil signal 
that the U.S. government expects will be a common signal among GPS, the 
European Union’s planned Global Navigation Satellite System (GNSS) known as 
Galileo, and Japan’s planned Quazi-Zenith Satellite System (QZSS) to augment 
the GPS over Japan. 

Civil users currently have access to C/A code only, as other signals (L2C, 
L5, and L1C) are not yet available. These future signals will allow more modern 
GPS receivers to take advantage of these signals in order to improve the PVT 
solutions they calculate. 

4. Control Segment 

Like the Space Segment, the Control Segment has Block II and Block III 
upgrades planned. These lag behind Space Segment modernization and are 
necessary in order to implement the capabilities designed and built into the 
satellite vehicles. Currently, the Block IIR-M satellites are capable of 
broadcasting signals that the Control Segment will not be able to support until 
Block III. The first Block I IF Control Segment delivery will replace the current 
system and provide an improved system architecture and system operator 
interface. The second delivery will add the SAASM capabilities described in 
section 2 of this chapter. After reductions in scope to the Block I IF Control 
Segment contract, this series of deliverables will serve largely as a stop-gap 
between the current Control Segment and the Block III Control Segment. In 
addition to enabling new SAASM capabilities, this block is essential for providing 
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the means to command and control the Block I IF satellites. The GPS Wing 
decided against upgrading the current system to support Block I IF satellites. 

5. User Segment 

The User Segment is pursuing a variety of modernization efforts to ensure 
that military users have the ability to take advantage of the latest capabilities 
available to them. Beyond making the necessary technical documentation 
available, the GPS Wing does not support efforts to develop or produce civil user 
equipment. User Segment programs include development of entire receivers, as 
well as new hardware that the User Equipment Support Division can install in 
existing receiver equipment. New capabilities to users will result from the 
following list of active programs: 

• Advanced Digital Antenna Panel (ADAP) for aircraft 

• Ground-Based GPS Receiver Application Module (GB-GRAM) for a 

variety of U.S. Army platforms and munitions 

• Defense Advanced GPS Receiver (DAGR) handsets 

• Miniature Airborne GPS Receiver (MAGR) 2000S 

• Modernized User Equipment (MUE) 

o the GPS Wing will not negotiate a contract to build MUE 

o the GPS Wing supports the development of the YMCA card 

to be used in MUE for receiving and processing the current military 
P-Code (known as P(Y)-Code when encrypted), the future military 
M-Code, and the coarse acquisition (C/A) code signals. 

Current military GPS users have receivers that are capable of operating 
within the currently unavailable SAASM architecture. 
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D. CURRENT REQUIREMENTS ENGINEERING METHODOLOGY 

1. The GPS Wing Systems Engineering Division 

The Systems Engineering Division serves as the clearinghouse for 
balancing requirements needs across GPS Segments and stakeholders. In 
particular, the Chief Engineer relies on the Requirements Branch, Integration 
Branch, Engineering Projects Branch, and Security Engineering Branch to 
support requirements engineering needs. The Test Branch supports verification 
of GPS requirements. 

The Integration Branch interacts with the product development teams 
within the Space, Control, and User Groups to resolve both requirements and 
design conflicts. The latter often results from differences in interpretation of the 
former by two or more development teams that must ensure effective interfaces 
between their deliverables. Because of the cross-segment interaction, the 
Integration Branch is well-positioned to manage most of the Interface Control 
Documents (ICDs) that govern the many GPS subsystem and stakeholder 
interfaces. However, there are instances where vendors that are responsible for 
developing a subsystem on one side of an interface also have control over the 
ICD. These vendors are called Interface Control Contractors (ICCs). This kind 
of arrangement causes conflicts because the vendor developing the subsystem 
on the other side of the same interface is left at a disadvantage when the ICC 
proposes ICD changes and implements them before the proposed changes are 
approved. 

With the input of the GPS program’s customers at AFSPC as well as other 
stakeholders, the Requirements Branch creates the Capability Development 
Document (CDD), the System Specifications, the Standard Positioning Service 
Performance Standards (SPS PS) and the Precise Positioning Service 
Performance Standards (PPS PS). Current and older versions of these 
documents apply to different segment development efforts, and the contracts that 
are relevant to those efforts. The other GPS stakeholders with whom the 
Requirements Branch interacts include the Aviation community’s representatives 
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from the Federal Aviation Administration (FAA), the U.S. Department of 
Transportation (DoT), and the International Civil Aviation Organization (ICAO). 
The SPS PS document includes a publicly releasable subset of information that 
is available in the GPS System Specification, top-level system interface control 
document (ICD), and some lower-level specifications and ICDs. 

The Engineering Projects Branch handles international and domestic 
regulatory issues that relate to the approval to broadcast signals in the manner 
approved by the appropriate regulatory bodies. The U.S. government files for 
rights to broadcast in pre-determined frequency bands and at negotiated power 
levels to ensure that other users of these and adjacent frequency bands suffer no 
harmful interference to their interests as a result of GPS operations. The U.S. 
Government must define the signals that the GPS broadcasts, and the 
Engineering Projects Branch handles the signal design of new signals to ensure 
that these signals meet GPS needs for supporting users and satisfying regulatory 
agreements. 

Once part of the Engineering Projects Branch, the recently-formed 
Security Engineering Branch assumed responsibility for all GPS security 
architecture needs. These include such areas of concern as the cryptographic 
protection of military signals for use by only authorized users as well as other 
features not disclosed by the program for security reasons. 


2. GPS Requirements Documents and Requirements Sources 

Figure 5 summarizes the diversity of requirements documentation that 
guides the definition and evolution of the GPS, and the stakeholder organizations 
that contribute to that documentation. With the exception of the Systems 
Engineering Division, the categories of stakeholders are grouped outside of the 
largest box in the figure that engulfs the names of the requirements documents. 

User communities such as the membership of the North Atlantic Treaty 
Organization (NATO) with its Standardization Agreement (STANAG), the 
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classified High-Accuracy Navigation Users (HANU), and the United States Coast 
Guard (USCG) are among the users outside of the DoD who influence the 
system. The civil users who stand out include the domestic and international civil 
aviation organizations. There is frequent interaction between the Department of 
Transportation’s (DoT’s) Federal Aviation Administration (FAA) and the 
international body of which it is a member, the International Civil Aviation 
Organization (ICAO). This interaction influences documents such as the 
Standards and Recommended Practices (SARPs), the description of the Future 
Radio System (FRS), and the Standard Positioning Service Performance 
Standards (SPS PS). 


System Data 
Suppliers 



Non-DoD 
Signal Design 
Sources, 
Constraints 


'Agreements with foreign 
governments, such as 
Japan (Quazi-Zenith 
Satellite System) and the 
European Union (Galileo) 


Figure 5. GPS Requirements Documents and Requirements Sources (After 

Alexander, 2006; and After Chief Engineer Navstar GPS Joint Program 

Office, 2006c) 
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Organizations that ensure that military users receive suitable receiver 
equipment include the 746 th Test Squadron and the Space and Naval Warfare 
Systems Command (SPAWAR). Beyond testing, SPAWAR is responsible for 
acquiring and integrating GPS receiver equipment on Navy and Marine Corp sea 
and air platforms. 

The customer paying for the GPS is the U.S. Air Force Space Command 
(AFSPC), which receives its funding from headquarters U.S. Air Force (HO 
USAF). In turn, AFSPC’s customer is the 50 th Space Wing and its 2 nd Space 
Operations Squadron known as 2SOPS. The Interagency Forum for Operational 
Requirements (IFOR) is a joint civil-military forum chaired by the AFSPC-level 
military and civil requirements representatives who ensure inclusion of civil 
requirements in GPS CDDs. USSTRATCOM is a cross-service organization that 
ensures it can provide direction to the operators of the GPS with Space Tasking 
Orders (STOs). These STO messages direct operators to include commands in 
the navigation message that change the behavior of the GPS in a theater of 
operations and benefit military users. The requirements levied by these 
organizations are now scrutinized by the Joint Requirements Oversight Council 
(JROC). 

The GPS cannot exist as a useful system without the contributions of 
various organizations. These include the Air Force Weather Agency (AFWA), 
which tracks solar flares that affect the transmission of GPS signals. Also 
noteworthy are the National Geospatial Intelligence Agency (NGA) mentioned in 
section B2 above and the National Security Agency (NSA) mentioned in section 
A above. The United States Naval Observatory (USNO) provides another 
atomic-based time reference against which to compare GPS time. The 850 th 
Joint Space Operations Center (JSpOC) has an interface with the GPS for 
receiving GPS data in a particular format. 

Lastly, the GPS inherits technical requirements and constraints as a result 

of the regulatory environment and agreements reached between the U.S. and 

other nations. These regulations and agreements encompass a range of 
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concerns such as military interests, compatibility—the degree to which there is or 
is no harmful interference) between two radio frequency-based systems, and 
even the definition of signal characteristics for possible common use in other 
Radio Navigation Satellite Systems (RNSSs) that could work with GPS. 

The GPS Wing considers all proposed requirements and changes with the 
requirements management process. This process requires a great deal of 
interaction among the different stakeholders represented within the GPS 
program. The next section describes this process. 

3. The GPS Requirements Management Process 

The requirements management process requires that the Systems 
Engineering Division consider the technical implications of adopting or changing 
requirements. Because of schedule and cost impacts that can result to the 
programs’ segment development contracts, this division cannot make decisions 
without coordinating with product development and functional groups. Figure 6 
shows the internal program interaction that occurs before a decision to 
rebaseline the GPS program’s requirements. This interaction is designed to work 
through the system’s Configuration Control Board (CCB) to coordinate all 
requirements baseline changes. All affected stakeholders contribute to the 
decision made through the CCB. 

The Systems Engineering Division performs much of the requirements 
analysis necessary to foster productive discussions about new requirements with 
the other stakeholders. This analysis includes eliciting, collecting, developing, 
and verifying customer and other stakeholder requirements before translating 
these into possible GPS segment development program requirements. The 
Engineering Review Board (ERB) is the forum for discussion within the Systems 
Engineering Division that occurs before forwarding proposed requirements 
(including changes) to a system CCB to involve the other program facets in the 
decision regarding whether and/or how best to implement a new requirement or 
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requirement change. The ERB rejects proposed changes to the program 
technical baseline if these proposals require more analysis before CCB 
consideration. 



•Technical •Reliability 'Usability Board (ERB) 

•Performance •Security 

Figure 6. GPS Wing Requirements Management Process (After Chief Engineer 

Navstar GPS Joint Program Office, 2006a, 2006c) 


Segment development programs will often propose changes to 
requirements for a few reasons. Not only does the GPS Wing have the ability to 
change requirements, but the vendors who control some of the interface 
definitions also have this ability. There may be technical challenges that are too 
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difficult or costly to overcome in the scheduled amount of time. Also, segment 
program requirements usually change through testing phases. Sometimes it is 
easier to change requirements than it is to satisfy them. This approach is 
beneficial when analysis reveals that the benefit of changing a requirement 
outweighs the cost. This can occur from a perspective of achieving a level of 
overall system performance, but may occur in the context of shifting the relative 
burden of satisfying a requirement from one segment to another. Vendors may 
propose such changes if in their own respective interests without regard for the 
best interests of the GPS program. If implemented, the vendor responsible for 
the other side of the interface would need to accommodate changes to interface 
requirement, and such an impact would have costs that the government would 
have to cover. More broadly, shifting any requirements via the CCB can have 
contractual impacts that the Contracts Division must provide as direction to the 
appropriate vendors to implement. 

Direction to vendors is likely to have cost impacts on the development 
contracts, and all cost impacts require coordination with the Program Control 
Division. Not surprisingly, technical and schedule changes have impacts on 
contracts that obligate the program to cover any costs. Thus, the Program 
Control Division finds itself coordinating with the other GPS Wing’s organizations 
to ensure that the program can meet proposed obligations before committing to 
requirements baseline changes that the Wing cannot implement within schedule 
and budget constraints. Segment development program managers help to 
assess the cost, schedule, and technical impacts to their respective programs as 
a result of proposed changes. 

E. IDENTIFIED RISKS AND CONCERNS 

There are forces that affect the ability of the GPS Wing to execute its 
development programs. Customers, operators, and users expect programs to 
remain on schedule and deliver promised capabilities. On the other hand, 
ambitious and perhaps unrealistic schedules increase the risk of program failure. 
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Loosely written contracts during Acquisition Reform era of the mid-1990s also 
limit the government’s ability to govern the execution of current contracts. As the 
GPS Wing tries to recover from the development problems of these programs, 
customers disregard past experience and continue to set high expectations for 
the Block III subsystem programs’ cost, schedule, and technical successes. 

1. Pressures from Customers, Operators, and Users 

As a joint military and international civil resource, the GPS attracts a 
tremendous amount of interest. It is a high-value and complex system that has 
provided PVT information for nearly two decades, and yet it is also under 
continuous development. Unfortunately, development has proceeded unevenly 
across GPS Segments. As the Block III satellite development proceeds, the lag 
in Control Segment development may continue due to unrealistic schedules and 
incomplete requirements. The first increment of the Block III Control Segment 
will implement only the capabilities available on the Block IIA, HR, IIR-M, and IIF 
capabilities. Block III satellite operations will not be possible until the second of 
four increments. Furthermore, there is a desire to accelerate the launch of the 
first increment of GPS III satellites, which would require the implementation of the 
second increment of the Block III Control Segment increment within two years 
from contract award. While the requirements definition has not finished and the 
issuance of an RFP is already behind schedule, there is a push to have the RFP 
issued by December 2006. 

These external pressures are setting the Block III Control Segment 
program up for future difficulties. It is not realistic to expect a five-fold increase in 
speed between contract award and operational capability without solid and 
complete requirements. It is more likely that requirements problems will prevent 
the Block III Control Segment—and probably the Block III Space Segment 
program as well—from adhering to their schedules. A lack of complete and well- 
defined requirements will probably cause integration problems as well. The 
outcome may be the continuation of the Control Segment lag that is evident in 
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Figure 5’s split arrows through the System Engineering box, which show that the 
implementation of some requirements in the SORD and ORD occur in the 
following blocks’ subsystems. If this pattern continues, the GPS program will not 
implement some Block III requirements until Block IV. 

Block III Control Segment and Space Segment successes are necessary 
to satisfy the needs of customers and users. Without availability of the Block III 
satellites and the second increment of the Block III Control Segment, the GPS 
Wing will not be able to sustain GPS constellation. If GPS Wing anticipates an 
inability to reach the milestones for these two deliverables before launching all 
Block 11F satellites, the fallback contingency would require the acquisition of more 
of these satellites before the production line shuts down. Users would have to 
experience the wait for new capabilities again, and the GPS Wing would need to 
reallocate near-term funds for the purchase of more Block I IF satellites rather 
than apply them to Block III contracts. 

2. Transition to an Entirely New Control Segment 

For the first time in its operation, the program is planning the most 
significant transition in the system’s history that involves the replacement of the 
Control Segment’s hardware and software in order to prepare for the addition of 
new capabilities. This immense technical challenge includes the daunting risk 
that something might not work correctly, thereby requiring the current system to 
serve as a back-up to prevent an interruption of service. The program has never 
faced a challenge that places the operation of the entire system at such risk. 
Previous challenges dealt with new block versions of satellites where the 
technical failure of a single satellite still left the GPS Wing with time to recover 
prior to the next launch. In order to mitigate schedule and constellation 
replenishment risk further, current launch practices have the Wing hold a 
previous version of satellite in reserve after launching the first new version of 
satellite. The Control Segment does not have this luxury because the Block 11F 
New Master Control Station (NMCS) must be ready to support the operation of 
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Block I IF satellites. Readiness depends on operator confidence in this system, 
because if the operators are not confident that it will function properly, they will 
not accept the new system. At the same time, the legacy MCS will not be able to 
command and control the new Block IIF satellites—if needed as a backup, the 
MCS would only be able to sustain the pre-Block IIF satellite constellation. 

The GPS Wing already faces a tough financial climate after dealing with a 
past oversight that resulted in a lack of vendor support for the transition of NMCS 
hardware and software to operational use. The increase in the Block IIF contract 
scope to include Control Segment transition support cost the Wing precious 
funds. The vendor for the Block III Control Segment should expect to satisfy 
requirements for transition activities also. 

3. Contractual Challenges for the Space and Control Segments 

The GPS operators were expected to command and control the GPS 
constellation using the NMCS before the turn of the millennium. The Block IIF 
contract designated the vendor as the single prime contractor and system 
integrator for its Space Segment and Control Segment deliverables. However, 
the vendor does little integration work as it attempts to overcome technical and 
schedule challenges for both major sets of deliverables. 

Operators were also expected to take on new responsibilities for the 
Launch, Anomaly Resolution, and Disposal Operations (LADO) subsystem that 
will replace a cross-program system that was to be decommissioned already. 
The GPS Wing must now fund the operation of this older system alone because 
other satellite programs have ended their reliance on it and because the GPS 
Wing has yet to overcome its LADO subsystem development program 
challenges. Problems with ambiguous requirements have caused problems with 
design and coding, as well as with the verification of these unclear requirements. 

Complicating matters more for the GPS Wing, the Block IIR satellite 
vendors find that they need to make changes to satellite flight software that 
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would make it incompatible with Block 11F Control Segment software undergoing 
test and evaluation. It would have been simpler and cheaper to modify the 
Control Segment software when the system was delivered and operational. An 
additional risk involves the loss of Block HR satellite vendor corporate knowledge 
if that vendor must delay fight software modifications long enough to necessitate 
laying-off key technical personnel. These people may find other programs or 
employers to support. After the Block I IF Control Segment becomes operational, 
the Block HR satellite vendor also might not be available via an active contract to 
work with Control Segment Support Division personnel to improve the interface 
between their subsystems. 

F. CHAPTER SUMMARY 

This chapter summarizes the basic functions of the Global Positioning 
System (GPS) and its segments, and describes the breadth of stakeholders who 
have an interest in the system. It also describes the organization of the GPS 
Wing that includes an expanded description of the Systems Engineering Division 
and the Branches within that division that are responsible for various types of 
requirements engineering activities. These activities include the requirements 
engineering activities that involve the system stakeholders and the requirements 
documentation they influence, as well as the GPS Wing requirements 
management process. The Acquisition Program Baseline (APB) highlights the 
relationships between subsystem development programs and the capabilities 
that they promise. As this chapter concludes, these subsystem development 
programs have not progressed as envisioned, and there are several 
requirements integration issues that the program must address in order to deliver 
working subsystems and capabilities without further significant costs, delays, and 
technical challenges. 
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III. LITERATURE REVIEW 


A. INTRODUCTION 

This chapter discusses GPS program requirements literature, and other 
requirements engineering literature that influences the GPS program’s handling 
of its requirements. Because there are so many requirements sources that 
impact the GPS’s development over its growing number of block upgrades, this 
chapter offers only a sample of GPS program requirements documents. This 
sample includes the Capabilities Development Document (CDD) provided by the 
GPS Wing’s customers; the most recent System Specification (SYS) written by 
the GPS Wing; one of many Interface Control Documents (ICDs) and Interface 
Specifications (ISs), and requirements management guidance in the form of GPS 
Wing Operating Instructions (Ols). Other resources include guidance from the 
Software Technology Support Center (STSC) and technical documentation for 
the Dynamic Object-Oriented Requirements System (DOORS) database. 


B. ORGANIZATIONAL LITERATURE 

1. Overview of GPS Requirements Sources 

GPS requirements sources are those documents and organizations 
identified in Figure 5 of Chapter II. These include the CDD and its predecessor 
documents, the ORD and SORD, as well as the hierarchy of specifications and 
ICDs that apply either to the overall system or to specific components of its 
segments such as a block of satellites. Other documentation that affects 
requirements development, management, and verification are GPS Operating 
Instructions (Ols). Two operating instructions are of particular interest to this 
research effort: the DOORS 01 and the Requirements 01 exist only in draft form 
as of September 22, 2006. 
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2. Capabilities Development Document (CDD) for the Block III 
Space and Control Segments 

The Capabilities Development Document will be a compliance document 
for the GPS Block III space and control segment contracts. This 440-page 
document signed by the 4-Star military leaders of Air Force Space Command 
(AFSPC) and the Headquarters U.S. Air Force (HQ USAF) presents system 
conceptual descriptions and gaps in capabilities that development efforts should 
close. Covered in the first section, Capabilities Discussion , these gaps are 
measured by comparing different environmental conditions in which the GPS 
might operate. Whereas the GPS operated effectively in non-hostile 
environments and those that existed during past military operations, 
environmental conditions have become less hospitable and the effectiveness of 
the GPS services has deteriorated accordingly. For example, the increase in 
non-GPS civil users of the frequency spectrum has adversely impacted civil 
users of GPS. Military users have also operated in environments that included 
harmful sources of interference to GPS. To overcome these challenges to 
operational capability effectiveness, the CDD serves to identify the highest 
system-level requirements that the GPS Wing will need to satisfy through its 
development programs. This CDD covers the subject areas shown in Table 2. 
The paragraphs that follow note the main themes in how requirements are stated 
throughout this CDD, but do not discuss specific requirements themselves. 
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• Capability Discussion 

• Analysis Summary 

• Concept of Operations 
(CONOPS) Summary 

• System Capabilities 
Required for the Current 
Increment 

• Program Summary 

• Family of System and 
System of Systems 
Synchronization 

• Electromagnetic 
Environmental Effects (E3) 
and Spectrum 
Supportability 

• Schedule and IOC/FOC 
Definitions 


• Threat Summary 

• National Security System 
and Information Technology 
System (NSS and ITS) 
Supportability 

• Intelligence Supportability 

• Assets Required to Achieve 
Initial Operational Capability 

• Other Doctrine, Organization, 
Training, Materiel, 

Leadership and Education, 
Personnel, and Facilities, 
(DOTMLPF) Considerations 

• Other System Characteristics 

• Program Affordability 


Table 2. GPS III CDD Subject Areas 


The Analysis Summary section discusses results and scores for various 
capability solution alternatives. While some of the results discussed come from 
testing or simulation, subject matter experts relied on their experience to specify 
other results subjectively. This comparative analysis is interesting and perhaps 
useful to a vendor who would like to understand the rationale for some 
requirements—especially when requirements suggest a specific combination of 
technologies to be developed further in order to provide a capability. However, 
the analysis-of-alternatives discussions do not introduce clear requirements to 
satisfy. Instead, recommendations keep the government’s options open 
regarding how it will eventually define requirements. These recommendations 
include mention of the needs to conduct further analyses, which means that it is 
up to the Wing to develop the high-level requirements for the areas analyzed. 
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The CONOPS Summary explains what the customers and operators want 
in terms of the logical and physical architecture of the system that the GPS Wing 
will deliver. With the CDD as a compliance document, these expectations 
become real requirements. If the delivered system does not conform to the 
CONOPS, the customers and operators will declare the system to be 
operationally unsuitable, which in turn would result in the failure of the 
development program. In addition to this CONOPS Summary, there is an 
appendix to the CDD that expands on the GPS architecture with the All Views, 
Operational Views, and System Views of the Department of Defense Architecture 
Framework (DoDAF). 

Requirements in the CDD are stated in terms of operational effect of the 
overall GPS. For example, Key Performance Parameters (KPPs) specify levels 
of PVT accuracy in units of meters, and availability of these levels of service in 
terms of percentages of time. Failure for a program to achieve a KPP could 
result in a decision to terminate that program. Many KPP values and system 
Threshold and Objective performance targets are defined in the 78-page CDD 
section titled System Capabilities Required for the Current Increment . This 
section includes quantifiable measures of system performance and rationale for 
the numbers chosen. The rationale can be useful to developers and customers 
alike as development of any part of the system continues and questions arise 
about the importance of achieving these goals. While some rationale explains 
operational needs, other rationale describes constraints in the form of laws or 
regulations that may change over time and, as a result, influence future program 
decisions. 

There are many requirements that the GPS must satisfy in order to remain 
interoperable with external systems, or that other DoD systems must also satisfy. 
These are identified in the Family of System and System of Systems 
Synchronization section. Cross-DoD system requirements for Families of 
Systems are specified in Capstone Requirements Documents (CRDs) that cover 
the areas of interest identified in the following titles: 
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• Close Air Support (CAS) 

• Combat Identification (CID) 

• Global Air Traffic Management (GATM) 

• Global Information Grid (GIG) 

• Integrated Satellite Operations (SATOPS) 

• Space Control. 

These CRDs are compliance documents for the GPS program that cover various 

system functional and nonfunctional requirements. Each of the CRDs represents 
a Family that the GPS belongs to. System of Systems include augmentation 
systems and additional payloads for the GPS. Desired interoperability with 
space-based and ground-based GPS augmentation systems is important to 
support the improvement of GPS accuracy for civil users. The GPS also meets 
requirements to support the implementation of the non-PVT service known as the 
Nuclear Detonation (NUDET) Detection System (NDS), and may need to add 
requirements to support capabilities desired in the concept known as the Distress 
Alerting Satellite System (DASS). 

The Electromagnetic and Environmental Effects (E3) and Spectrum 
Supportability section is noteworthy because of its simplicity and brevity. This 
section requires that subsystems in both the Space and Control Segments be 
able to operate effectively in their respective electromagnetic environments. It 
also requires that the GPS operate in compliance with both the ever-changing 
international and domestic regulations and policies that govern frequency 
spectrum use. Therefore, it is most practical to cite these requirements by 
reference and omit discussion of goals and rationale. 

The section titled Schedule and IOC/FOC Definitions appears to contain 
no requirements, but in a document called a “Capabilities Development 
Document,” it seems appropriate that some terms related to these capabilities 
are defined in order to facilitate the statement of requirements within or beyond 
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the CDD. Of particular interest to GPS program managers, system engineers, 
customers, operators and users are the definitions of Initial Operational 
Capability (IOC) and Full Operational Capability (FOC). These definitions 
depend on the implementation of technologies in all three GPS segments. 

While describing system-related requirements, several sections also 
include development-related requirements that are not requirements that the 
operational GPS would need to satisfy. These requirements are appropriate for 
a capabilities document that guides system development. Some of these, like 
Threat Summary and the Supportability sections describe issues that are 
important. These nonfunctional requirements issues cover system technical 
characteristics, performance, reliability, security, and usability. These sections 
are as follows: 

• Threat Summary 

• National Security System and Information Technology System 

(NSS and ITS) Supportability 

• Intelligence Supportability 

• Assets Required to Achieve Initial Operational Capability 

• Other Doctrine, Organization, Training, Materiel, Leadership and 

Education, Personnel, and Facilities, (DOTMLPF) Considerations 

• Other System Characteristics, such as 

o Hazardous Materials 

o Safety and Health 

o Security Classification Guidance 

• Program Affordability 

These sections include system requirements, especially in the case of personnel 
and facilities that are critical parts of the Control Segment. Many of the types of 
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requirements in these sections include threshold values that equal their objective 
values, thereby showing that the requirements are either satisfied or they are not. 


3. System and Segment Specifications 

The specifications documents focus on system and subsystem 
requirements that support the delivery of a subset of required capabilities 
described in the CDD. These documents are different than the CDD in their 
organization and their focus. They contain a more detailed view of the system, 
its performance, and the specific user needs to be satisfied. System 
Specifications (SYS) and Segment Specifications (SS) are similar in their 
structure. A description of the Space and Control System Specification follows 
below. 

In order to avoid redundancy, the GPS III Space and Control Segment’s 
System Specification names 103 other requirements documents as sources of 
requirements that must be satisfied. These sources include the following items: 

• DoD Handbooks and Standards 

• Air Force Directives, Instructions, Manuals, and Pamphlets 

• DoD Directives, Instructions and Manuals 

• GPS Wing Documents (ICDs, ISs, the Program Protection Plan, 
and Computer Resource Support Plan) 

• GPS Modernization System Threat Assessment Report (STAR) 

• Agreements with federal agencies and international organizations 

• Miscellaneous aviation, frequency spectrum, acquisition, safety, 
security, design, test, certification, and operational guidelines and 
standards 

• Specifications and reference documents from other agencies and 
programs 
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These documents fall into two categories: 1) compliance documents that are to 
be treated as an extension of the SYS, and 2) reference documents that can act 
as guides or sources of other relevant information. To prevent any problems with 
requirements ambiguity, the SYS states that its guidance supersedes any 
requirements that are in conflict with the SYS. Lower tier requirements (below 
the CDD) comply with the following order of precedence: 

1. System Specification (SYS) 

2. Segment Specification (SS) 

3. System-Level Interface Control Documents (ICDs) and Interface 

Specifications (ISs) 

4. Segment Product/Development Specifications 

A brief system description section describing the functions and capabilities 
of the next generation Space and Control Segments precedes the discussion of 
GPS III system-level requirements that contain ‘shall’ statements. Even though 
this SYS is not a User Segment specification, it describes system performance in 
terms that are relevant to user equipment measurements like pseudorange and 
calculations like PVT information. Requirements statements also address other 
user concerns, such as the level of availability of GPS services. For services that 
do not exist, effectivity is used to help describe the incremental deployments of 
capabilities in the SYS. For both the Space and Control Segments, there are 
four effectivities, or increments, defined in this SYS. Only the final full- 
capabilities effectivity definition for each of these two Segments matches. 
Because the Control Segment’s subsystem is not up to date, the first Block III 
Control Segment increment addresses only unsatisfied requirements from the 
ORD that the CDD absorbed. 

In addition to increasing the breadth and quality of services, the GPS must 
also continue providing the current services. In order to do so, new parts of the 
GPS Segments must maintain the current external interfaces, and either replace 
or continue to support internal interfaces with existing Segment subsystems. The 
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GPS has external interfaces with additional GPS satellite payloads and systems 
that belong to non-AFSPC organizations like those described in Figure 5. GPS 
internal interfaces connect the various GPS Space Segment vehicles with each 
other, the Control Segment, and the User Segment. 

The remaining requirements are nonfunctional and address the following 
areas of concern: 


• Safety 

• Security 

• Computer 

• Environmental 

• Quality 

• Design & Construction 

These are all important nonfunctional 
successful fielding of new capabilities. 


• Personnel 

• Training 

• Logistics 

• Packaging, handling, 
storage, and transportation 

requirements that have an impact on the 


A Quality section discusses the methods for verification of requirements to 
ensure that the system will meet its performance criteria, comply with design 
characteristics, satisfy interface needs, and operate properly. System Engineers 
and Program Managers can verify requirements using the following methods to 
be tracked for each requirement in the DOORS requirements database: 


• Inspection 

• Analysis 

• Demonstration 

• Test 

• Special methods to provide aviation safety assurance. 
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The government specification documents often use the word shall, but 
there is no current government source that restricts the use of this word or 
defines what it means when compared to other words like must and will. 
Vendors find it necessary to provide definitions for these terms in order to 
prevent any conflicts from arising about their meanings. At the beginning of its 
software requirements specifications (SRSs) written under contract for Boeing 
Navigation Systems, Lockheed Martin Integrated Systems and Solutions 
(Gaithersburg, MD) provides definitions that are paraphrased below: 

• A ‘shall’ statement identifies all requirements or parts of 
requirements that trigger design, coding/production, and unless otherwise 
stated, testing. A ‘shall’ statement has a unique number for identification 
and traceability. 

• A ‘must’ statement identifies a requirement that is one of two things: 
o a system design constraint 

or 

o a provision being provided to the designer by the 
government and upon which the designer depends-government 
furnished property (GFP) or equipment (GFE). 

• A ‘will’ statement is used like a ‘must’ statement for instances in 
which the government is to provide GFP or GFE, but the system being 
designed does not depend on this property or equipment. 

Because there is no need for unique identification or traceability, ‘must’ 
and ‘will’ statements are not numbered. 

4. Interface Control Documents (ICDs) and Interface 
Specifications (ISs) 

GPS program uses ICDs and ISs to describe the interfaces between GPS 
subsystems. There are external interfaces with systems belonging to other 
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organizations, and there are internal interfaces that describe the characteristics 
of the information exchanged between different GPS Segments’ subsystems. 
Dozens of these ICDs and ISs describe internal interfaces, and while the 
government controls some of these interface documents, contractors exercise 
control over others. This section discusses the government-vendor conflict over 
these documents, and describes the structure of one of the interface documents. 

a. The Emergence of ISs in the GPS Wing 

Current practice establishes the Interface Control Contractor (ICC) 
for a given ICD as one of the vendors for two new subsystems that will interface. 
For example, an ICD describes the interface between the Block I IF Control 
Segment and the Block MR satellites. The Block HR satellite vendor is the ICC 
for this interface. Problems with ICC control over ICDs prompted changes to 
how the GPS Wing baselines interface descriptions. As a result of these 
problems, a previous GPS Wing Commander decided to change how the GPS 
Wing handled certain interface documents. 

Vendors took exception to changes proposed for ICDs that 
described GPS signals. Because ICDs require the affected parties to agree to 
changes, and agreement requires that the parties provide their signatures on 
Interface Revision Notices (IRNs), the lack of vendor signatures on these ICDs 
prevented the GPS program from implementing necessary changes to signal 
descriptions. The GPS Wing Commander attempted to regain control over these 
ICDs by changing the names of these documents to Interface Specifications and 
treating them the way that the Air Force Satellite Control Network (AFSCN) treats 
its own ISs—the AFSCN issues changes to ISs without ensuring that the affected 
parties approve of the changes (Alexander, P., personal communication, August 
31, 2006). In the case of the AFSCN, it is infeasible to gain approval from all 
affected parties because there are so many. The GPS Wing Commander 
implemented the same approach by arranging for some ICDs to become ISs 
because it is also impractical to get the approval of so many GPS users when 
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changing ICDs might affect them. The GPS Wing Commander argued that if 
users did not provide their consent to ICD changes, then vendors would not need 
to consent to interface changes either. Therefore, ICDs describing the interface 
between one-subsystem and many affected parties became ISs. The structure 
of an IS is the same as that for an ICD. ICDs continue to describe one-to-one 
interfaces and require signatures from each of the two affected parties when 
there is an agreement on changes. 

The emergence of ISs in the GPS Wing did not solve all contractual 
problems with vendors. The GPS Wing found it necessary to include ‘shall’ 
statements in ICDs and ISs so that vendors would ensure that their deliverables 
would interface with existing GPS subsystems properly. Without ‘shall’ 
statements in interface documents that require verification testing, vendors 
considered such testing to be beyond the scope of their contracts. Instead of 
defining and describing interfaces with the least amount of ambiguity possible— 
perhaps by offering detail and background information—GPS program ICDs and 
ISs go beyond providing descriptions by stating requirements for vendors to 
satisfy. According to SETA contractor Patricia Alexander, “good old engineering 
common sense should lead to verification tests,” but without a ‘shall’ statement, 
the vendors’ business managers will not agree to verify that their deliverables will 
interface with other GPS subsystems correctly (Alexander, P., personal 
communication, August 31,2006). 

b. Space-to-User Interface Specification 

SETA contractor ARINC is the ICC for the IS that describes the 
interface between the Space Segment and the GPS navigation users who belong 
to the User Segment. Because this document is for an internal interface, there 
are no external specifications or standards that apply. This document focuses on 
Space-to-User requirements exclusively. 

This IS describes the carrier frequency, ranging code, signal 

structures, navigation signal, and other signal characteristics of interest to two 
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important categories of GPS stakeholders who work with their GPS Wing 
counterparts: 1) user equipment developers who must process GPS signals, and 
2) satellite developers who must provide the signals. In addition, there are also 
many definitions and equations provided to ensure a common understanding 
among these two groups of stakeholders so that they develop subsystems that 
are compatible. Going beyond the description of the interface, there are several 
‘shall’ statements in this document that require both interfacing subsystems to 
support specified levels of service. 

As a result of changes to this IS, vendors submitted Letters of 
Exception (LOEs) to state their non-concurrence with proposed changes that 
became approved. Even though the GPS Wing approves ISs unilaterally, the 
Wing chose to provide some of the LOEs in the IS in order to document the 
vendors’ concerns publicly. These vendors based their exceptions on cost, 
schedule, or performance impacts that would result if—in order to satisfy newly- 
baselined requirements—the vendors needed to increase the scope of their 
efforts beyond the scope defined in their contracts. Vendors submit these letters 
because they need to justify the impact of changes. The GPS Wing can respond 
to these letters in a few ways: 

• The GPS Wing can authorize a Letter of Exception to stand and 
document it in the IS revision, 

• The GPS Wing can reject the letter and pursue contractual 
discussions to resolve the issue 

• The GPS Wing can agree to provide some form of relief to the 
vendor that submits the letter. 

5. GPS Operating Instructions (Ols) 

There are two draft GPS Wing Ols that are especially relevant to this 
paper: 1) the draft DOORS 01 for the Dynamic Object-Oriented Requirements 
System tool used by the government and vendors for the GPS program, and 2) 
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the incomplete draft Requirements Engineering 01. These will be used together 
in order to guide GPS program requirements development, management, and 
verification. 

a. DOORS 01 

The Requirements Branch of the Systems Engineering Division 
maintains the DOORS database, capturing requirements and allowing this 
database to interact with those DOORS databases of the vendors who also use 
this tool. This requirements management tool is widely-used for complex 
systems like the GPS. 

Of the two ways in which a development program can manage 
requirements in DOORS, the GPS program uses the document-oriented 
approach specified in the draft GPS DOORS 01. “GPS has adopted a document- 
based approach whereby DOORS modules are created that map one-to-one to 
the program’s documents” (Chief Engineer GPS Wing, 2006 draft). The draft 01 
also directs the GPS program to place each requirements document into a 
separate module. All modules are linked in a hierarchy. Objects within modules 
exist for each section heading and requirement paragraph. Related modules can 
be grouped into DOORS Projects, such as for a segment subsystem of the GPS 
like Modernized User Equipment (MUE) or the Block I IF Control Segment. 

Because some requirements are classified, the draft DOORS 01 
requires that an up-to-date duplicate of the GPS DOORS database reside on a 
stand-alone computer located in an appropriately secure vault. In addition to the 
duplication of unclassified GPS requirements, this separate database includes all 
classified requirements with all of the links necessary to trace up to higher-level 
requirements or assess impacts on lower-level requirements. Access to this 
classified database and the classified requirements that populate it is limited to 
those who have the appropriate security clearances and need-to-know. 

DOORS attributes help to clarify and categorize requirements 
information captured in objects. The draft GPS DOORS 01 Attachment 8 

recommends that each program adopt the definable attributes listed in Table 3. 
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• Segment/Block 
Allocation 

• Classification level 

• “Is” Requirement (T/F?) 

• Performance Area 

- Accuracy, Integrity, etc. 

• Technical Performance 
Measure 

• Requirement ID 

- Only for objects 
containing a reqt 

• Requirements POC 

• Risk 

- Low, medium, high 


• Verification Method 

- Analysis, test, demo, etc. 

• Verification POC 

• Verification Status 

- Verified, not verified, 
passed, failed 

• Verification Level 

- System, Segment 

• Priority 

- KPP, non-KPP 

• External Reference 

- Links to non-DOORS doc. 

• Rationale 

• Comments 


Table 3. Draft GPS Wing DOORS 01 Recommended Attributes 


In addition to the recommended attributes, assigned attributes 
include such characteristics as the object’s creator, creation date, and last 
modification date. 

For example: The Requirement ID attribute is a unique identifier for 
each requirement. The Requirement ID attribute remains blank for non¬ 
requirement objects, and a sorting feature allows for a document’s (or module’s) 
requirements to be identified and presented in a view that does not include the 
other objects. 
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As requirements change, additional attributes can help to track 
these changes. Changes are managed using the GPS Wing requirements 
management process that supports the Configuration Control Board (CCB), as 
shown in Figure 6 and repeated as Figure 7 below. The CCB can only control 
the requirement Verification Method and Rationale attributes. Other helpful 
attributes include the ‘Was’ Requirement attribute to identify the previous wording 
of a requirement, the Proposed Change attribute to identify the proposed 
wording, Reason For Change text attribute, and the Attribute/Link Change 
Summary attribute to summarize changes to existing requirement attributes as 
well as changes to the links to other requirements. 



•Technical •Reliability "Usability Board (ERB) 

•Performance "Security 


Figure 7. GPS Wing Requirements Management Process (After Chief Engineer 

Navstar GPS Joint Program Office, 2006a, 2006c). 
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The 01 also requires the inclusion of the Contract Data 
Requirements List (CDRL) items in DOORS. The CDRL items shall include the 
following documents: 

• The System Specification 

• Segment specifications 

• Prime item development specifications that trace requirements to 

their respective higher-level specifications 

• Interface Control Documents (ICDs) 

• Test plans, procedures and reports (to support verification of 

specification requirements) 

Linking is a powerful DOORS feature that facilitates requirements 
analyses. Traceability and impact analyses deal with external links that focus on 
requirements relationships up to parent modules (or documents) and down to 
child modules. The 01 requires the appropriate steps to avoid describing 
requirements in ways that complicate the ability to link objects that contain 
requirements. One example includes the requirement for DOORS modules to 
refrain from using compound requirements, which are multiple requirements 
attached to only one ‘shall’ statement. Such statements should be broken apart 
into individual ‘shall’ statements and then re-linked to show the relationship 
between them. Another example is to use DOORS tables in which each cell 
contains no more than a single requirement. When it is not possible to capture a 
requirement fully in a single ‘shall’ statement, then the most effective practice is 
to establish internal links (or links within a module) to explanative objects that do 
not contain ‘shall’ statements. These objects can include tables, figures, 
equations or other sources of information that help to describe the requirement 
fully. Besides traceability and impact analyses, other analyses related to links 
include finding orphan requirements objects and suspect links. Orphan 
requirements do not have parent requirements to satisfy. Suspect links can 
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emerge when the contents of linked objects change, and as a result, give reason 
to question the validity of the links to those objects. 

When approved, the DOORS 01 will require that DOORS users to 
refrain from using generic DOORS links. Instead, GPS DOORS users will use 
requirements links to connect requirements objects in different modules. 
Similarly, DOORS users will also use test and verification links to connect test 
and verification data to higher-level requirements objects. The ability to define 
different types of links allows DOORS users to either trace through requirements 
objects or find test and verification objects more quickly. Finally, special links 
shall be defined for various situations as needed, including the linking of 
proprietary documents and also for linking internal GPS Wing documents for 
Wing use only. 

In addition to describing the utility that the DOORS database can 
provide, the 01 also discusses other issues that are mainly DOORS technical 
issues rather than functions it performs. These issues include configuration 
management, module output formats and reports, technology and administrative 
support, management, and user training. An important technical issue that 
affects the effectiveness that DOORS can have for a program involves the details 
of how to prepare documents for DOORS importation. Most often these files will 
be Microsoft Word or Excel documents. Often these documents will include 
figures and tables that must be handled appropriately in order to facilitate linking 
the information to other documents/modules. For example, each cell within a 
DOORS table for a given module can be linked separately to other modules. 

Lastly, the draft DOORS 01 explains the roles and responsibilities 
for the following program personnel and organizations: 

• DOORS Management Working Group (DMWG) lead by the 

DOORS Government Project Lead 

• DOORS Information Technology Support 

• DOORS Configuration Manager and Training Liaison Manager 
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• System Engineering Lead 

• Program Management Lead 

• DOORS Module Points of Contact, and the Integrated Product 

Teams Coordinator who assigns them 

• Interface/Specification Control Contractors 

• Program Managers 

• Configuration Control Board Reviewers 

• DOORS users 

The people who occupy these roles and participate in these groups are charged 
with ensuring that the GPS program requirements are captured fully, that 
proposed baseline configuration changes are tracked, and that updates are 
made when proposed changes are approved. The government also works with 
vendors to ensure that the vendors’ DOORS database technology and practices 
remain compatible in order to support the exchange of DOORS information. 

While the DOORS 01 draft was available for review on March 23, 
2006, the GPS Chief Engineer and GPS Wing Commander have not 
implemented this document as policy as of September 22, 2006. While the 
review of this draft continues, the GPS program also faces information 
technology funding challenges that will limit the effectiveness of this policy. The 
GPS Wing currently has 21 licenses for this database tool to share among even 
more customers, vendors, and other stakeholders. The GPS Wing also lacks 
funding for the classified workstation to handle classified requirements. 

b. Requirements Engineering Ol 

At the time of publishing for this thesis, which will be completed by 
September 22, 2006, the Requirements Ol existed only in draft form. The draft 
guidance emphasizes the requirements functions and associated processes for 
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carrying out these functions thoroughly. The three requirements engineering 
functions are listed in Table 4 below: 


• Requirements 

• Requirements 

• Requirements 

Development 

Management 

Verification 

- Identifying 

- Establishing 

- Verifying products 

stakeholders 

resources 

- Establishing & 

& their needs 

- Establishing 

maintaining 

- Synthesizing 

requirements 

verification 

requirements 

providers 

environment 

- Prioritizing & 

- Capturing 

- Verifying 

categorizing 

information 

procedures 

requirements 

- Managing 

- Using peer review 

- Validating 

change 

process 

requirements 

- Creating 

- Verifying products 

- Developing a 

products 

- Assisting supplier 

high-level 

- Managing 

verification 

baseline 

supplier 

- Updating JPO 

- Documenting 

documentation 

System Eng. Plan 

requirements 


(SEP) 


Table 4. Requirements Engineering Functions listed in 01. 


The draft DOORS 01 emphasizes all three groups of functions 
described in the Requirements 01. While much work remains before this 01 is 
complete and approved, the intent appears to include supporting GPS program 
needs by ensuring well-defined requirements to populate the DOORS database. 

The draft Requirements 01 also includes a checklist for systems 
engineers to use when writing requirements. The checklist includes the following 
questions about potential requirements statements: 
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Is it clear? 


• Is it as short as it can be? 

• Does it apply to a defined type of user? 

• Does it have a reasonable priority? 

• Is it verifiable? 

• Is it a single requirement? 

• Is its source shown? 

• Does it have a unique identifier? 

• Is it genuinely a user requirement, not a design constraint? 

(Chief Engineer GPS Wing, 2006 rough draft) 

This checklist will guide engineers and program managers who may not 
remember the characteristics of a good requirement. It will also help to 
encourage a consistent level of requirement statement quality across GPS 
subsystem acquisition programs. 

C. REQUIREMENTS ENGINEERING LITERATURE 

1. Software Technology Support Center (STSC) 

Jim Van Buren and David A. Cook of Draper Laboratory and the Software 
Technology Support Center provide a history of requirements engineering 
challenges and lessons learned in their paper titled Experiences in the Adoption 
of Requirements Engineering Technologies. They categorize requirements 
engineering into the following five categories: 

1. Elicitation - getting customers to state their exact requirements 

2. Analysis - 

a. making qualitative judgments about system requirements 
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b. beginning a high-level design by decomposing the system 
into components and specifying their interfaces 

3. Management - dealing with requirements changes 

4. Validation and Verification - 

a. Validation - building the right system (to satisfy customers) 

b. Verification - building the system right (to satisfy 
requirements) 

5. Documentation - 

a. structuring written specifications 
or 

b. choosing and structuring a requirements database 

A major challenge facing many programs is the reality that many 
customers’ view of requirements differs from that of developers. Whereas 
developers see a requirement as something that is testable and may be 
prioritized, many customers think of requirements in terms of their overall needs. 
Skilled requirements elicitation from customers helps to overcome this barrier to 
defining good requirements for developers. 

There are many well-established approaches to requirements analysis, as 
well as tools to complement these approaches. These approaches include 
requirements modeling techniques such as traditional structured analysis and 
objected-oriented analysis. (In spite of its name, DOORS is not an object- 
oriented analysis tool.) Even with proven tools and approaches, programs run 
into difficulties when tools enforce a process that is inconsistent with a 
development program’s process, or when the people who implement the 
approach and tool lack sufficient training to be effective with them. Van Buren 
and Cook note that well-funded programs typically overanalyze requirements 
while other programs tend to analyze requirements less to save precious funds. 
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The requirements management portion of the STSC paper addresses how 
increased requirement volatility also increases programmatic risk. While volatility 
is a natural result when building a useful product, it is desirable to control 
volatility that results from the poor elicitation and specification of requirements. 
Requirements management tools can help track and measure requirements 
volatility, and also support the traceability and impact analyses up and down a 
requirements hierarchy. These tools provide information that should not only 
support internal programmatic decision making, but also the important interaction 
with customers who need to understand the impacts of requirements changes. 

Developers should plan requirements validation and verification as early 
as the elicitation phase. Customers and users will not accept a system if it 
doesn’t meet their expectations, so developers must elicit those requirements 
that are necessary to ensure that the right system is built. This validation is one 
measure of requirements quality. The other measure is requirements 
verification. If requirements are not verifiable, it will be impossible to 
demonstrate that the system is built correctly. The customers and users are 
essential to ensuring system validation and verification. 

Requirements documentation involves specifying “an overall description, 
external interfaces, functional requirements, performance requirements, design 
constraints, and quality attributes” (as cited in Cook & Dupaix, 1999). These are 
explained in sources like withdrawn DoD standards MIL-STD-2167A and MIL- 
STD-498, as well as industry standards like ANSI/IEEE-STD-830-1993 and 
EIA/IEEE 12207. Requirements management tools can also support 
requirements documentation needs. 

2. DOORS Database Documentation 

The Dynamic Object-Oriented Requirements System (DOORS) database 
is a Telelogic product that is widely used for managing requirements of complex 
development programs in industries like aerospace and defense. Using modules 
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and objects within DOORS, the GPS program uses this database product to 
store and track program requirements. Among this tool’s strengths are the 
traceability and attributes features. 

Modules are files that are used to capture requirements about an area of 
concern. For example, the GPS program uses separate files for each system 
specification and segment specification. All lower-level specifications are also 
separate modules that are linked to higher-level modules, as appropriate, in 
order to enable requirements traceability or impacts analyses. Objects in 
DOORS are distinguishable entities within modules, and these have unique 
DOORS identification numbers assigned to them automatically. 

As Figure 8 below shows, if all GPS III requirements were loaded into 
DOORS and linked properly, it would be possible to look at the GPS III System 
Specification to see which requirements statements at different levels are related. 
In this notional example, traceability analyses help to ensure that the 
implementation of lower-level requirements results in the required subsystem or 
overall system performance. Similarly, impact analyses allow one to see how 
changes made to objects in higher-level modules will affect objects in lower-level 
modules. The person conducting the traceability and impact analyses can also 
choose the depth, or number of levels, that are of interest in either type of 
analysis. For example, one may only wish to see immediate requirements traces 
or impacts that go no further than one module up or down, respectively. With 
computer mouse clicks, both of these features allow the DOORS user to move 
from object to object across modules in order to access related requirements. 
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GPS III CDD Module 


Object 1 


Object 2 


Object 3 


Object 4 


Object 5 


Object 6 


In-Link traceability 


Upward (traceability) 
and downward 
(impact) analyses 
are possible for 
notional “Object 6” in 
the GPS III System 
Specification Module 


Out-Link impacts 


GPS III System Specification Module 


Object 1 

Object 2 

Object 3 




Object 4 

Object 5 

Object 6 



JL 



GPS III Space Segment 


Specification Module 


Object 1 


Object 2 


Object 3 


Object 4 


Object 5 


GPS II 

Control Segment 

Specification Module 

Object 1 

Object 2 


Object 3 


r 



Dbject 4 

Object 5 

Object 6 



Figure 8. Notional GPS III Example of DOORS Traceability and Impacts. 

In addition to linking requirements, it is easy to include other important 
information in DOORS to support system acquisition activities. In particular, 
modules and objects can capture design and test information. When linked 
properly, it is possible to trace test events to the design features to be verified, 
and continue to the requirements that the design features are to satisfy. 

When creating links, it is possible to define different types of link 
characteristics in link modules: 

• Many-to-many : each object can have many in-links and out-links 
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• Many-to-one : each object can have many in-links, but only one out- 

link 

• One-to-many : each object can have only one in-link, but many out- 

links 

• One-to-one : each object can have only one in-link and one out-link 

Link module subdivisions called linksets include information about the 
links from one module to another or within modules. When dealing with only two 
modules, four linksets define links from Module 1 to Module 2, Module 2 to 
Module 1, Module 1 to Module 1 (for links between objects in Module 1), and 
Module 2 to Module 2. The direction of links is important, as shown in Figure 8. 
While there is a default DOORS link module, it is also possible to define different 
types of link modules for different purposes in order to improve organization, 
facilitate analysis, or limit user access. 

DOORS objects have the ability to be described by up to 32 attributes. 
Attributes are characteristics that some requirements will likely share, and some 
of these are determined by the DOORS database while others are chosen by the 
system engineer who manages DOORS. The modules that include objects can 
have an unlimited number of attributes to pass on to the objects within the 
modules. 

Tables 5 and 6 show the types of attributes and attribute types that one 
can expect to find in DOORS. While it is possible to edit some of the system 
attributes for either modules or objects (shown in italics), others are read-only. In 
addition to system attributes and DOORS-preset attribute types, there are also 
user-defined attributes and attribute types. The information contained within 
Tables 5 and 6 comes from the Help menu provided in Telelogic AB’s DOORS 
7.1 database. This Help menu serves as a comprehensive DOORS 7.1 users 
manual. 
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System Attributes for 

System Attributes for 


Modules 

Objects 

• 

Created By 

• Absolute number 

• 

Created On 

• Created By 

• 

Description 

• Created On 

• 

Last Modified By 

• Created Thru 

• 

Last Modified On 

• Last Modified By 

• 

Mapping (one-to-one or 

• Last Modified On 


many-to-many; only for 

• Object Heading 


link modules) 

• Object Short Text 

• 

Name 

• Object Text 

• 

Prefix 

• (advanced system 



attributes that show 



status information) 


Table 5. System Attributes for Modules and Objects. 
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Base Attribute Types 

• Text 

• String 

• Integer 

• Real 

• Date 

• Enumeration 

- this allows attribute to 
take on one of a 
predefined set of values 

• Username 


User-Created Attributes 

• Kilogram 

- Base type Integer 

• Dollar 

- Base type Integer 

• Percentage 

- Base type Integer 

• Deviation 

- Base type Real 

• Priority 

- Base type Enumeration 

• Rationale 

- Base type String 


Table 6. Attribute Types—Base & Some Possible User-Created. 

DOORS allows the ability to take user-defined attributes from other 
modules and import them into the module a user is working on. In the case of 
GPS, it could be helpful to use existing module and object attributes defined for 
an existing block of space vehicles to help describe the requirements for the 
corresponding DOORS objects and modules used for future block acquisition 
programs. 

D. CHAPTER SUMMARY 

This chapter reveals the various requirements engineering literature that is 
available to the GPS program and to the broader systems development 
community. While it is important not only to define a development program’s 
system requirements clearly, it is also important to organize and manage these 
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requirements effectively so that program managers and systems engineers can 
support the design and verification of systems. It is also important to implement 
methodologies—a combination of models, tools, and techniques—that are 
aligned with these requirements engineering activities rather than disrupt them. 
The DOORS database is a tool that is aligned with the GPS Wing’s requirements 
practices. The database attributes, linking, and traceability features allow users 
to store and organize information in a way that supports analysis and decision¬ 
making. The next chapter addresses the implementation of these ways to 
improve how the GPS program handles all three areas of its requirements 
engineering activities: requirements development, requirements management, 
and requirements verification. 
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IV. RESEARCH ANALYSIS AND RECOMMENDED 
APPLICATION OF STUDY 

A. INTRODUCTION 

The literature reviewed and the interviews conducted with GPS Wing 
personnel serve as the foundation for this chapter. Recommendations span the 
requirements engineering activities that include how the GPS program elicits, 
stores, manages, evaluates, and changes its program technical baseline. This 
chapter attempts to answer as completely as possible the research questions 
posed in Chapter I. Many of these conclusions demonstrate that effective 
solutions do not necessarily require new material solutions like a new database. 
Some changes in institutionalized practices alone offer new possibilities for 
improving requirements engineering and decision-making agility. The Dynamic 
Object-Oriented Requirements System (DOORS) is a capable requirements 
management tool in use by the GPS Wing. While any tool has room for 
improvement, DOORS is adequate for the manner in which it is used, has been 
successful in the past, and has a tremendous amount of untapped potential to 
support the GPS program requirements engineering needs. 

B. CHANGING TO A REQUIREMENTS-CENTRIC APPROACH 

As shown in Figure 5 and repeated as Figure 9 below, the GPS Wing 
elicits its requirements from the Headquarters of the U.S. Air Force (HQ USAF), 
Air Force Space Command (AFSPC), U.S. Strategic Command 
(USSTRATCOM), and the Interagency Forum for Operational Requirements 
(IFOR). These organizations provide their inputs by means of documents that 
exist to serve a broad audience of systems engineers, program managers, 
customers, and users. The format of these documents makes them useful to all, 
but it is not a format that is most practical for the engineers and managers who 
access the requirements and study them meticulously. The chapter, paragraph 
and sentence structure may appeal the most to the customers because it is 
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familiar, but this structure makes it more difficult for engineers and program 
mangers to organize their requirements in order to ensure they deliver the 
product that the customer wants. With a requirements-centric use of the DOORS 
database tool for the GPS program, the GPS Wing could streamline its 
requirements engineering activities and reap benefits that go from development 
activities through design verification and system deployment. However, the GPS 
Wing has no plans to demonstrate and take advantage of this model. The draft 
DOORS 01 shows that the GPS Wing will follow the document-centric model, 
which follows the lead of AFSPC after it refused to provide a requirements- 
centric ODD (Campbell, J., personal communication, July 25, 2006). 



DoS 

Bilaterals* 


FCC 


ITU (United_ 

Nations) 
Non-DoD 
Signal Design 
Sources, 
Constraints 


Customers 




HQ USAF 


IFOR 





Customer 

USSTRATCOM 


Customer 

AFSPC/DRN 




User Communities 


GPS 

CONOPS 


SORD 


ORD 


Systems Engineering 



SARPs 


User Equipment 
Test & Integration 


Block 1 


Block 2 


: : _ x _ 

Block 3 

System 


System 


System 

Specs 


Specs 


Specs 


Specs, Interface definitions, & commitments ICDs 



T 


Global Positioning System 


'Agreements with foreign 
governments, such as 
Japan (Quazi-Zenith 
Satellite System) and the 
European Union (Galileo) 


Figure 9. GPS Requirements Documents and Requirements Sources (After 

Alexander, 2006; and After Chief Engineer Navstar GPS Joint Program 

Office, 2006c) 
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The DOORS database stores specification information in a manner that 
mimics each document’s structure. Users treat it as a document repository. For 
these documents, each of which is a DOORS module, the objects are arranged 
in the order they appear as headings or paragraphs in the source document. As 
used by most GPS Wing account holders, DOORS offers no advantage over 
using the source requirements documents themselves. The lack of links 
between requirement objects and the limited use of user-defined attributes 
prevents anybody from conducting queries that would otherwise help to trace, 
filter, or sort through requirements objects of interest. Thus, these users are not 
exploiting the most powerful features that DOORS offers. 

Current users have exposed another flaw with the document-centric 
approach that prevents them from exploiting the capabilities of DOORS. 
Because they see a format for information that mimics the source documents, 
users tend to expect to have word processing and spreadsheet functionality that 
allows editing. For example, Microsoft Word and Excel source documents must 
be updated first before uploading the entire blocks of text or entire tables as 
DOORS objects to replace the existing objects. The need to perform this kind of 
procedure causes some to question the value of the DOORS tool, but this user 
expectation is evidence of a DOORS tool education problem and an 
implementation weakness that results from the document-centric approach 
specified in the draft GPS DOORS 01. These users do not appreciate the 
capabilities of databases in general. 

The requirements engineering goal for the GPS program should be to do 
away with the various requirements documents it tracks, and instead focus on 
the structure of the system’s requirements. Much of the information contained in 
these documents is background information that does not describe requirements 
that the program must satisfy for its customers. This information could go into 
documents that provide background information, but it should not get mixed with 
new requirements because of the problems that can and do result from the 
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ambiguity regarding whether a statement is a requirement or not. Requirements 
are not all listed together in the current documents. 

Because it is in wide use by vendors and the GPS Wing, the DOORS 
database is available and able to support building requirements hierarchies that 
can take over the requirements roles played by capability and specification 
documents. While the DOORS tool can support other uses, the definition of 
DOORS requirements links can eliminate the problem that would arise by using 
the default DOORS links to connect requirements objects with other objects such 
as Test and Verification objects. While these objects can be linked to 
requirements objects, it is useful to be able to filter out these objects if one only 
wishes to see requirements objects that are linked with program-defined 
requirements links. The DOORS files that the GPS Wing and its vendors could 
share would use the structure shown in Figure 10: 
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DOORS Super-Tier Project Folder 




Figure 10. DOORS Database Structure 

This structure applies to the document-centric structure in use as well as 
the requirements-centric structure that the GPS program could use. One 
advantage that is not implemented for the various GPS subsystem development 
programs is the linking feature that supports traceability. While the DOORS 01 
will mandate that programs not use the default DOORS links, this will not be an 
issue for most programs because they have not linked their requirements objects 
yet. There are links defined between the Block III Space and Control ODD and 
System Specification that reside in their own DOORS project folder. This project 
folder will eventually have objects that are linked to the separate DOORS project 
folders for the Block III Space Segment and Block III Control Segment programs 
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when those get underway. In general, programs that are represented by project 
folders in Figure 10 could link their requirements objects across modules and 
other project folders that reside in the same super-tier project folder. 


1. Requirements Development 

AFSPC provided the GPS Wing the June 3, 2005 CDD instead of 
agreeing to provide requirements in a manner that supports a requirements- 
centric use of the DOORS database. In doing so, the customer made a decision 
that affects how other customers and stakeholders communicate their 
requirements and needs to the GPS Wing. The long-term impact will include a 
greater amount of work for all customers. 

By employing a requirements-centric approach, the GPS program could 
have taken advantage of existing requirements in order to limit the amount of 
requirements development necessary for new deliverables. Rather than reinvent 
legacy requirements, the GPS Wing could reuse these legacy requirements and 
focus on developing new requirements only. As an example, consider the U.S. 
civil aviation community’s interest in GPS service continuity. While also 
interested in new civil signals and the capabilities that would come along with 
them, this stakeholder group provided detailed backwards compatibility 
requirements through the IFOR to emphasize the civil priority for the GPS to 
continue providing existing services at equal or greater levels of service quality 
(Cryderman, J., personal communication, July 24, 2006). These levels of service 
quality are measured in such general terms as availability, integrity, and 
accuracy. These types of quality are enumeration choices for the Performance 
Area recommended attribute type in the draft DOORS Ol (see Table 3). The 
development of these “backwards compatibility” requirements from this GPS 
stakeholder group would be much simpler and prone to fewer omissions and 
errors if the GPS program reused legacy requirements objects rather than rewrite 
legacy requirements into new capability or specification documents. This type of 
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approach would facilitate efficient documentation of requirements across 
generations by ensuring that legacy requirements that are still valid continue to 
drive development. 

For a new subsystem development program, legacy requirements could 
be assigned a newly defined effectivity attribute choice among the already 
existing enumeration choices. The new effectivity attribute for legacy 
requirements would link these requirements to new subsystem development 
programs. Figure 11 shows a notional example of this requirements reuse 
practice by including two Block 11F Control Segment requirements among the 
Block III Control Segment requirements. The current document-centric practice 
would have many requirements objects duplicated unnecessarily in different 
DOORS projects folders within a super-tier project instead of limiting new 
requirements objects to those for new requirements only. For this suggestion to 
work, legacy requirements would need to be stored in a format that makes them 
reusable. In other words, the program would need to define and use effectivity 
attributes for the legacy requirements that are stored as DOORS objects— 
something not done for most DOORS objects in the GPS program. 
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Figure 11. Example of Existing Requirement Reuse in the next Block Upgrade 


Beyond GPS, this cross-generation benefit would apply not only to legacy 
systems that are continuously upgraded, but also to development efforts for new 
system requirements when the new system will replace the old system 
completely. In the DoD acquisition structure and while using a requirements- 
centric approach, it could be possible to export requirements database 
information from one program office (or Wing) to the database of another. The 
requirements will change, but the objects could be rewritten while preserving the 
types of requirements the new program office must address. However, the new 
program’s decision makers would need to weigh the costs versus benefits to 
overcoming technical challenges if it becomes necessary to transfer the 
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information from one requirements management database to a dissimilar tool. If 
customers like Air Combat Command and Air Force Space Command provided 
tool-specific requirements-centric inputs and enforced the use of that single tool 
by its acquisition Wings, then tool incompatibility would not be a big issue. 

2. Requirements Management and Documentation 

Requirements management deals with the decisions regarding 
requirements changes. Requirements documentation deals with how 
requirements are stored, handled, and presented in reports. Effective 
documentation of baselined requirements helps decision makers access the 
requirements information they need in order to support efforts to change 
requirements. Requirements documentation also addresses linking requirements 
to organize them better and support analyses, tracking changing requirements 
attributes, and generating formal reports. The goal for performing these 
requirements management and documentation functions well is to improve the 
speed, quality, and confidence of engineering and program management 
decisions. 

Because the GPS program works with vendors that also use DOORS, one 
of the most important requirements documentation and management issues 
involves the transfer of requirements information between the GPS Wing and its 
vendors. Currently, this transfer occurs with the exchange of requirements 
documents. The government provides high-level requirements documents that 
are compliance documents on a contract, and the vendors share the lower-level 
specifications they produce in order to satisfy these higher-level requirements. 
The GPS Wing technical experts, who consist primarily of FFRDC personnel and 
SETA contractors, review the vendor-produced documentation in order to ensure 
that the requirements contained within these documents are complete and 
accurate enough to address requirements in higher-level specifications. Linking 
and reviewing a hierarchy of requirements stored in DOORS could accomplish 
the same goal more efficiently and with greater assurance. Instead of 
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transferring documents, vendors could provide their DOORS objects, modules or 
project folders for lower-level requirements instead. Vendors have already 
exchanged DOORS extracts with the GPS Wing, but neither party relies on this 
method for the purpose of exchanging requirements information that will undergo 
review. 

Creating a hierarchy of requirements in DOORS with clear parent-child 
relationships would ultimately support efforts to verify that a produced subsystem 
satisfies its requirements. This requirements development method would result 
in a database for managing requirements and eventually supporting design 
verification activities. The GPS Wing would be the only organization with copies 
of all DOORS project folders within its super-tier project folder. As indicated in 
Figure 12, the GPS Wing would exchange copies of DOORS project folders with 
the appropriate vendors. Doing so ensures a common baseline understanding of 
each program’s requirements between the GPS Wing and the appropriate 
vendors. Vendors would begin by using their copies of the government-created 
DOORS database information to grow requirements trees to greater depths. 
Within the project folders shown in Figure 12, changes to the modules for the 
government-defined system and segment specifications would require 
government coordination. 
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Figure 12. Synchronizing GPS Wing and Vendors’ DOORS Information 


If there is a change in practice to a requirements-centric approach for the 
GPS program, some stakeholders will still prefer to have access to document- 
style descriptions of requirements. For these people, the DOORS database can 
support the production of reports that emulate this style, and these stakeholders 
could produce reports themselves by establishing accounts and learning how to 
use the tool. However, much of the background information found in many such 
documents would have to come from sources other than the requirements 
objects. This information could reside in non-requirements objects in DOORS or 
in documents that exist to preserve background information. 
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The system Configuration Control Board (CCB) personnel in the Systems 
Engineering Division’s Requirements Branch have both read and write access, 
but most requirements stakeholders should have read-only access to the GPS 
DOORS database. Organization of GPS program requirements in a 
requirements-centric fashion and granting broad read-only access would benefit 
engineers by allowing them to study requirements in a format that supports their 
requirements organization and traceability needs best, and support other 
stakeholders without causing a significant long-term inconvenience. The short¬ 
term inconveniences would include establishing accounts and receiving the 
training necessary to navigate the database, trace requirements, and produce 
reports. Requirements stakeholders should develop a familiarity with DOORS 
that matches the familiarity that many have with word processing and electronic 
mail applications. If the goal is to improve the management of GPS 
requirements, then the solution will also need to include the enforcement of 
consistent practices that support this goal. 


a. Requirements Defined, But Not Needed 

Current requirements are not the only ones worth managing. It 
would be useful to track requirements that no longer apply to any development 
program because they have been satisfied or because of a reduction in technical 
scope for existing programs. The draft DOORS 01 identifies the Was’ 
Requirement attribute as a way to track these requirements. If the requirement 
becomes valid again as a result of new activities for a new program, a program 
manager or systems engineer could recommend the assignment of the new 
effectivity attribute that indicates the new program to which the Was’ 
Requirement should belong. 

There are other possible Was’ Requirements that may never 
become requirements for the GPS Wing and its vendors to satisfy. Even so, it is 
still useful from a requirements management perspective to retain these 
requirements in the database for reference purposes. Someone involved in the 
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GPS program may not know that a requirement is no longer valid or understand 
why. Requirement history is important for understanding why some requirements 
fade and others remain valid from one generation to the next. This 
understanding reduces the amount of time wasted when reevaluating a 
requirement. 


b. Requirements Needed, But Not Defined 

There are cases when requirements development activities for a 
capability do not account for all requirements that need to be satisfied in order to 
fully implement the capability. 

For example, the GPS Wing Space Segment Group has already 
supported the production and launch of Block HR satellites that can broadcast the 
M-Code ranging signal. However, because of a reduction in the scope of the 
Control Segment’s Block I IF contract, the Control Segment Group does not have 
a requirement for monitoring such a signal or for providing an appropriate 
Navigation message to combine with it. This example shows how requirements 
development is complete for one segment, but not for the entire system. 

As a practice to be added to the GPS Requirements 01, the GPS 
Wing should specify the development and management of system-level and all 
segment-level requirements necessary to implement a capability. The M-Code 
monitoring capability is now planned for the first increment of the Block III Control 
Segment. 

A special case of undocumented GPS Control Segment 
requirements could have been solved easily by using DOORS with a 
requirements-centric approach. The Control Segment’s offline tools were 
developed without GPS Wing support in order to support the existing needs of 
the Control Segment operators. Before the GPS III Space and Control CDD 
documented these requirements, engineers could have created a separate 
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module for these requirements objects and linked them as needed without having 
a requirements document to rely on. 

c. Supporting Analyses for Baseline Changes 

After requirements definition and baseline approval, analysis 
activities continue throughout the system’s lifecycle. A requirements-centric 
approach to requirements management and documentation would support these 
analysis activities. In a manner similar to other program organizations, the GPS 
Wing may decide or be required to conduct What-lf drills to determine the effects 
of possible changes to requirements. The drills may result from internal 
questions that arise due to technical development challenges, disputes between 
vendors developing opposing sides of subsystems that will share an interface, or 
because a customer like HQ USAF would like to study alternative requirements. 
During these drills, the subject matter experts conduct the technical analysis 
necessary to assess the impacts of requirements changes on subsystem 
programs. Currently, these individuals rely solely on their expertise and diligence 
because they do not have a requirements-centric implementation of DOORS to 
support their analysis. The DOORS standard view offers a sequential list of a 
module’s objects—headings, paragraphs, tables, and figures extracted from each 
requirements document in the order that they appear in a document. A 
traceability view would show how child objects are linked to parent objects. In 
short, additional analysis develops requirements further. The ability to trace up 
or assess impacts down a properly linked requirements hierarchy would support 
these efforts. However, there are no links established to support requirements 
traceability analyses. 

The GPS Wing would benefit from DOORS use practices that 
support rapid identification of all related requirements and allow users to then 
proceed with their analysis. A requirements-centric approach in which 
hierarchies of requirements are linked properly would improve analysts’ and 
decision makers’ collective confidence that the conclusions take into account all 
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relevant requirements. The customer would benefit by receiving rapid and well- 
researched answers with which to make decisions about changing requirements. 
In addition to technical confidence, program decision makers and customers 
would also benefit from the stronger confidence in cost and schedule analyses 
that accompany technical analyses. These decisions are made using the system 
Configuration Control Board (CCB) process that impact the working groups and 
organizations named in Figures 6 and 7. Organizations include the appropriate 
vendors as well as the various GPS Wing organizations such as the Systems 
Engineering Division, affected Program Managers’ Groups, the Program Control 
Division, and the Contracts Division. Working groups that provide 
recommendations to the CCB include the GPS Wing Engineering Review Board 
(ERB) and Interface Control Working Groups (ICWGs). Changes approved via 
this CCB process require subsequent updates to relevant documentation and 
DOORS objects that mirror this documentation. 

3. Requirements Validation, Verification and Testing 

Requirements validation and verification are other forms of analysis that 
would benefit from a requirements-centric approach to requirements engineering. 
If successful, validation and verification events bring closure to open 
requirements. Clear traceability of lower-level requirements up to System-level 
requirements supports final validation, verification, and testing. 

a. Validation 

Customers with government DOORS accounts would have access 
to the information needed to validate system-level, segment-level or even lower- 
level requirements. Invalidating requirements derived from the CDD or system- 
level requirements will reveal misunderstandings about a customer’s intent. If 
interested in greater levels of detail, customers would have an opportunity to see 
how their requirements develop and understand issues that arise. Access to 
DOORS should encourage customers to interact more with the GPS Wing to 
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resolve issues. Because customers often do not appreciate the challenges that 
their requirements can cause or the consequences of those challenges, 
customers may be willing to modify or relent on requirements that are not as 
important as once thought. As a result, this additional insight would offer 
opportunities for customers to contribute to solutions that save cost and schedule 
for more important capabilities. 

b. Verification 

Establishing and using a hierarchy with clear and accurate 
relationships would eliminate the ambiguity that exists presently and fuels 
conflicts between vendors and GPS Wing personnel during verification events. 
DOORS can support the development and management of requirements in this 
way to make requirement verification progress easier to assess. 

For example: The Block 11F System Specification, Block I IF Space 
Segment Specification, and the Block I IF Control Segment Specification all have 
requirements traceability and verification matrices. In its matrix, the System 
Specification shows internal links among its paragraphs. In the Space and 
Control Segments’ specifications, their matrices define links between their 
respective requirements and requirements in the System Specification. This type 
of traceability format is full of errors, cumbersome, and lacks depth beyond one 
level. A requirements-centric approach to using DOORS would offer the 
opportunity to provide greater accuracy and depths of requirements traceability in 
the GPS Wing database. While the authors of the GPS III Space and Control 
System Specification wrote that specification to address the CDD’s requirements, 
not all requirements are linked correctly or unambiguously to parent 
requirements: 

• some system specification requirements trace to ODD statements 
that are not requirements statements 
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• some system specification requirements trace to unrelated CDD 
requirements statements 

• some system specification requirements trace to nothing in the 
CDD 

(Campbell, J., personal communication, July 25, 2006) 

These kinds of situations lead to difficulties in verifying 
requirements. By providing clear visibility into the relationships in a requirements 
hierarchy, a requirements-centric approach to requirements engineering would 
help the GPS Wing prevent such traceability and completeness problems from 
occurring. In the requirements-centric approach, child requirements derive 
directly from parent requirements, thereby eliminating the possibility that a lower- 
level document has parentless requirements (orphans). This approach would 
provide better visibility into whether a parent requirement has all of the child 
requirements that are needed to support eventual satisfaction of the parent 
requirement. The linkage of requirements in the DOORS project folders shared 
by the GPS Wing and the appropriate vendor share would support requirements 
traceability without the need to corroborate the requirements statements of 
multiple specifications. 

c. Testing 

A hierarchical structure of linked requirements implemented with a 
tool like DOORS can simplify verification planning and speed requirements 
verification itself. Test failures would be easier to track by using requirements 
attributes that address test status. These attributes could implement 
enumeration types such as not tested, pass, or fail. The default attribute could 
be not tested until the systems engineer conducts a sanctioned verification test. 
Sanctioning authority would depend on the level of requirement and stage of 
testing. For example, a system-level test would require GPS Wing authority to 
modify a requirement’s attribute. As another example, a vendor would have 
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jurisdiction over subsystem component-level tests for which these kinds of lower- 
level requirements would exist initially within projects created in the vendor’s 
DOORS project folder, and then be transferred to the GPS Wing for inclusion 
within its corresponding DOORS project folder. 

C. REQUIREMENTS CONTROL 

Even if the GPS program adopts a requirements-centric approach for its 
requirements engineering activities, the benefits of this approach would be 
limited to some extent by the amount of control the GPS Wing exercises over 
requirements. Vendors exercise control over Segment specifications that, in 
some cases, have an effect on the work of other vendors that support other parts 
of the GPS program. Government control over the System-level and Segment- 
level specifications would help the GPS Wing in its role as the prime integrator of 
GPS subsystems. Ultimately, the GPS Wing is responsible for successful 
integration, and must demonstrate this success to its customers. Vendors should 
expect to support, but not lead the integration effort of the subsystems they 
deliver. 

To ensure requirements discipline and facilitate systems integration, the 
GPS Wing should retain control over System-level and Segment-level 
requirements for the GPS III Space Segment and Control Segment contracts. 
The program learned through experience already that it is risky to allow a prime 
subsystem vendor to be the major subsystems integrator of deliverables for 
different Segments. Vendors seeking to pass verification events have two 
choices when their products fail to pass a test in the specified environment—they 
can either redesign a product so that it will pass, or the vendor can relax the 
requirements until a product passes its test. The latter option is often less 
desirable to the government because the government is stuck with the 
consequences. Vendors’ customers (like the GPS Wing) will most likely prefer a 
choice over whether there will be a product redesign—which would add schedule 
and cost to a program—or whether it would prefer to relax the vendor’s 
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requirements. Without understanding the impacts, the government is not likely to 
accept the relaxation of a requirement. 

D. THE DRAFT REQUIREMENTS OPERATING INSTRUCTION (Ol) AND 

THE DOORS Ol—EXPECTED IMPACTS AND RECOMMENDATIONS 

The GPS Wing’s direction regarding requirements engineering activities 
will be captured by two operating instructions—the Requirements Ol and the 
DOORS Ol. The Systems Engineering Division would like both approved before 
the end of 2006. The Requirements Ol will offer important advice about defining 
requirements effectively, which should make it an effective companion document 
for the DOORS Ol. The DOORS Ol will discuss links to support traceability, but 
the document-centric focus on the ODD and specifications make linking 
requirements more difficult. The DOORS Ol would have a greater positive 
impact on the GPS program if it directs a requirement-centric approach to 
requirements engineering and directed the use of its listed attributes. 

The Requirements Ol’s checklist for defining requirements will help 
program personnel to improve the statement of requirements. Shown already in 
Chapter 3, the checklist is as follows: 

• Is it clear? 

• Is it as short as it can be? 

• Does it apply to a defined type of user? 

• Does it have a reasonable priority? 

• Is it verifiable? 

• Is it a single requirement? 

• Is its source shown? 

• Does it have a unique identifier? 
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• Is it genuinely a user requirement, not a design constraint? 

(Chief Engineer GPS Wing, 2006b draft) 

This checklist of questions will help personnel make a determination about 
whether to restate a requirement or to eliminate it. Restating a requirement may 
actually require that the requirement statement be longer or be broken into 
distinct parts in order to capture its entire intent or satisfy multiple stakeholders 
throughout the GPS program. The goal should be to capture all the information 
that is necessary to design the system, include nothing more than what is 
necessary, and document this information in a way that prevents ambiguity. 

Mandating the recommended attributes listed in the draft DOORS 01 
would help ensure consistent requirements documentation practices across the 
GPS program. Doing so would also help to satisfy the Draft Requirements 01 
checklist by ensuring answers to some of the checklist questions, such as those 
that address verification and priority. Of all the GPS subsystem development 
programs, the User Segment Group’s Advanced Digital Antenna Panel (ADAP) 
DOORS project folder demonstrates the best example of using attributes among 
the GPS Segment’s programs. Most other subsystem development programs 
use no attributes other than the attributes assigned automatically by DOORS. 
The reason why the nonuse of attributes is likely to continue stems from the 
document-centric approach to requirements management that allows program 
personnel to access requirements documents without accessing DOORS. Much 
of the information that would exist as requirements attributes does not exist in 
these requirements documents. Consequently, decision makers will not have 
convenient access to this information. 

E. THE USE OF THE WORD SHALL IN SPECIFICATIONS, INTERFACE 

CONTROL DOCUMENTS AND INTERFACE SPECIFICATIONS 

The statement of requirements in ICDs and ISs underscores a problem 
the GPS Wing faces with its vendors. ICDs should merely describe external and 

internal interfaces rather than also specify requirements. However, vendors 
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claim that without shall statements, certain activities are out of the scope of their 
contract. The use of ‘shall’ statements in ICDs and ISs solves the government’s 
problem of getting vendors to verify that the systems they deliver will interface 
properly with the other GPS subsystems. However, because the intent of 
interface documents is to describe rather than require, the GPS Wing will need to 
ensure that future contracts include requirements for verification of not only the 
vendor’s deliverables, but also the proper interface of these deliverables with 
other GPS subsystems. In the absence of a shift away from specification 
documents, compliance documents such as system or segment specifications 
would be a more appropriate place to levy verification requirements for 
interfaces. In a requirements-centric model, verification requirements would 
need to exist at the segment or system level also. 

Vendors have clear and particular definitions for the words like shall, must, 
and will. If the vendors agree to include ICDs, ISs, and specifications as 
compliance documents on their contracts, then these documents shall include 
the word shall to help designate vendors’ requirements. The remaining risk with 
respect to the use of this word is that the government has not issued a current 
and precise definition of shall or any other such words to be agreed upon by all 
vendors. (The government rescinded MIL-STD-961, which defined shall, will, 
and should.) Instead, it is the vendor who defines the meaning of these as well 
as other terms, such as must, that may not have military-wide or even GPS 
program-wide accepted meanings. For a program in which there are different 
vendors responsible for developing and producing different subsystems, any 
inconsistencies in vendors’ use and interpretations of these kinds of terms 
increase the risk of incompatibilities due to unsatisfied requirements. In addition 
to technical issues, differences in interpretation over whether a statement is a 
requirement or not can also lead to contractual difficulties that delay the pursuit of 
a necessary technical solution. 

The government should redefine the definition of shall and any other 
words it intends for use in defining the contractual obligations of the government 
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and its vendors. After doing so, the government should also ensure proper and 
consistent use of these terms in its capabilities documents and specifications. 
The GPS program has a Block III CDD for the Space and Control Segments that 
uses statements with words other than shall that appear to be requirements 
statements. For example, the word should appears throughout the CDD— 
including several instances in Section 6: System Capabilities Required for the 
Current Increment . MIL-STD-961 stated that the word should relates to a goal. 
However, there is no current government-approved definition for should that 
applies to military acquisition programs, and this word is not defined in the CDD 
either. 

F. CHAPTER SUMMARY 

This chapter offers suggestions for improving the GPS program’s 
requirements engineering and system integration effectiveness by standardizing 
on technology already available to the program. Currently, the GPS program is 
not practicing an effective way to develop, manage, verify requirements; or 
include consistent practices across subsystem acquisition programs. Although 
the GPS program and its vendors have a tool capable of supporting a 
requirements-centric approach, they are not using the DOORS tool to do so. 
However, the program has taken steps in 2006 to improve its requirements 
engineering activities by writing operating instructions that provide direction to 
program personnel; but there are still opportunities to improve the draft DOORS 
01. The draft Requirements 01 will eventually close a gap in program direction 
regarding requirements engineering. While this chapter recommends 
abandoning a document-centric approach in favor of a requirements-centric 
approach, current realities that face the program will likely divert decision¬ 
makers’ collective attention towards overcoming higher priority financial, 
schedule, and technical challenges. 
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V. CONCLUSIONS 


A. INTRODUCTION 

This research proposes ways to improve the requirements engineering 
work at the Air Force’s GPS Wing, the acquisition program office for this civil- 
military system. The ultimate benefit is faster and better-informed decisions 
made by GPS program leaders who must balance the needs of multiple 
stakeholders. These stakeholders rely on this system for positioning, velocity, 
and timing services. While decisions ultimately depend on human interaction 
and persuasion, organizing the requirements information effectively can lead to a 
better decision-making process. When relevant information is available in a 
useful standard format, people make more informed, rational and confident 
decisions. 

For the GPS Wing to be effective, all three segments—Space, Control, 
and User—must work together. As a result, the GPS Wing must ensure proper 
allocation of requirements across these segments and integrate the subsystem 
acquisition program deliverables from these segments. The Wing should 
consider its investment of time, training, and funds carefully when evaluating 
requirements methodologies that support integration efforts. The GPS Wing and 
its vendors use the same DOORS database tool and have experimented with 
exchanging DOORS files. By changing its model and processes to take 
advantage of the features offered by DOORS, the Wing can achieve more 
efficient integration. 

B. CURRENT PROGRAM REALITIES 

While the program managers and engineers of GPS Wing recognize the 
need to improve requirements engineering practices, current realities facing the 
program pose challenges to doing so. The program has seen different rates of 
progress on all three Segment modernization efforts because of technical, 
schedule, and cost constraints. While the program must deliver on its technical 
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obligations and overcome its schedule delays, the current resource-constrained 
defense acquisition environment adds another obstacle to meeting the emerging 
needs of civil and military users. Customers like HQ USAF have even asked the 
GPS Wing to compress future capability deliveries while the GPS Wing faces 
repeated reductions in its technical staff. The GPS and other development 
programs operate under a schedule-driven environment in which the Control 
Segment Group is attempting to meet a December 2006 target for releasing its 
already-delayed Request for Proposal (RFP) for the Block III Control Segment 
contract. By having a schedule-driven RFP rather than an event-driven one, the 
GPS Wing faces an increased risk that it will miss requirements. 

The GPS Wing has recognized that it should improve its requirements 
engineering practices by drafting the Requirements and DOORS Operating 
Instructions (Ols). These are unprecedented documents that will standardize 
requirements engineering across the Wing for the first time. The completed draft 
DOORS 01 has room for improvement, and the enforcement of this 01 for older 
programs may have costs that do not outweigh the benefits. Long term benefits 
are possible when using a requirements-centric approach that emphasizes 
reusing existing requirements objects. Creating new requirements objects to 
replace legacy objects would also make requirements development easier. 
When completed and approved, the Requirements 01 should provide the 
guidance that is necessary to promote a consistently high level of quality for 
requirements across Segment development programs. 


C. KEY POINTS AND RECOMMENDATIONS 

This research paper discusses all three facets to a requirements 
engineering methodology: models, tools, and techniques. 

First, a requirements-centric approach or model would benefit the GPS 
Wing’s requirements development, management and verification efforts. 
However, this kind of approach would require changes to the other two facets of 
the methodology: tools and techniques. 
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Second, the Wing can strengthen its requirements engineering efforts by 
taking advantage of underutilized DOORS features such as attribute definition 
and linking to support requirements traceability. 

Third, the GPS Wing has begun to define techniques for the first time in 
the draft Requirements and DOORS Operating Instructions. Implementation and 
enforcement of these Ols will help improve the requirements quality. 

Even with a shift in its requirements engineering methodology, there are 
other ways that the GPS Wing could improve the way it handles its requirements. 
The GPS Wing would also serve its customers better by insisting to its vendors 
that the GPS Wing control the top-level requirements baselines and interface 
definitions. 

For example: The GPS Wing learned from its experiences with the Block 
HR Space contract and the Block I IF Space and Control contract that government 
loss of control over the technical baselines for subsystem deliverables causes 
contractual and integration difficulties. These difficulties increase costs and 
delay schedules. 

As the system integrator, the GPS Wing could reduce integration costs 
and ensure that subsystem deliverables work together properly. When vendors 
seek a change to requirements or interfaces that the government controls, the 
government can then lead the decision-making process to decide how it would 
prefer to handle the proposed change. The current situation is untenable where 
the GPS Wing finds itself forced to help one vendor adapt to changes made by 
another vendor. 

In its contracts with vendors, the GPS Wing should also provide a single 
set of definitions for key terms that help to define the roles and obligations of the 
GPS Wing, other government entities, and all vendors who develop and produce 
GPS subsystem deliverables. Disputes and questions over contractual 
agreements cost the GPS Wing precious funds and development time. If the 
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GPS Wing defined these key terms, vendors would not need to specify 
definitions for these terms that may vary from one vendor to another. 

Over the last decade, the GPS Wing has learned from its contractual 
experiences that it must do a better job of specifying clear and complete 
requirements to vendors in order to ensure that subsystem deliverables are 
operationally suitable. 

One example of inadequate requirements specification involves the lack of 
vendor support for the transition to operations of the Block IIF Control Segment 
software and hardware deliverables. Another example comes from the vendor 
belief that ‘shall’ statements in ICDs and ISs are necessary to ensure that 
vendors verify the performance of interfaces between their deliverables and other 
GPS subsystems. 

The government needs to ensure that it specifies a complete set of 
requirements that cover all system acquisition needs. Unfortunately, bad 
program experiences are the motivation behind the draft Requirements 01 to 
improve and standardize GPS Wing requirements engineering practices. 


D. AREAS FOR CONDUCTING FURTHER RESEARCH 

Even if the GPS Wing were already following the recommendations of this 
research paper, there would still be other areas to search for improvements to 
the GPS program’s requirements engineering methodology. Rather than making 
the best use of available resources such as the DOORS tool, research could 
focus on evaluating the combination of tools and techniques that would support 
the GPS programs interests best. 
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